El propósito de una auditoría de seguridad es identificar todos los ataques y las actividades ilegales o maliciosas que pueden estar tomando lugar en su servidor. Los criminales se han vuelto cada vez más inventivos y, como DBA, usted puede no haber considerado o siquiera haber estado consciente de todas las actividades que pueden poner sus datos en riesgo.
Para este fin, realizar un seguimiento de quién ha accedido, quién ha intentado acceder y qué ha sido hecho por la gente con acceso se han vuelto actividades cruciales en identificar y apuntar las vulnerabilidades en su estrategia de seguridad.
En este artículo, proveeré algunas líneas de guía acerca de cómo usted puede crear una estrategia de auditoría adecuada para su ambiente y qué características de SQL Server pueden serle útiles en su búsqueda por la estrategia de auditoría perfecta.
La importancia de la auditoría
¿Por qué auditamos? La meta número uno debería ser asegurar que su política de seguridad es suficiente para mantener la información de su negocio y de sus clientes segura y que sus riesgos están siendo manejados.
El gobierno y otros entes reguladores de industrias específicas han prescrito requerimientos que deben ser cumplidos para ser certificados o evadir multas y otros castigos. Algunos de estos requerimientos son PCI, HIPAA, SOX, etc. En algunos casos, las únicas regulaciones pueden ser aquellas impuestas por el negocio en sí.
Si su SQL Server no está siendo auditado, usted se está exponiendo a una gran cantidad de problemas potenciales. Los problemas más comunes son ataques externos, actividades no sancionadas por usuarios autorizados y errores.
Tener la auditoría en orden permite un análisis forense después de que un incidente ha sido identificado. Lo que le permitirá implementar contramedidas adecuadas y responsabilizar a los empleados por sus acciones.
Estrategia de auditoría
Idear una estrategia de auditoría sólida está en el centro de cualquier esfuerzo exitoso de auditoría. Es bastante tentador auditar simplemente todo, pero en un ambiente del mundo real, esto no es viable y puede llevar a problemas como:
- Una sobreabundancia de datos, lo que hará difícil identificar cualquier problema.
- Grandes cantidades de espacio de almacenamiento requeridas.
- Afectar de manera adversa al desempeño.
Antes de implementar cualquier solución de auditoría, lo siguiente necesita ser considerado:
- ¿Qué es lo que legalmente usted requiere auditar?
- ¿Por cuánto tiempo se requiere que mantenga los datos auditados legalmente?
- ¿Cuándo espacio de almacenamiento tiene?
- ¿Cuál es el propósito de los datos auditados? ¿Es sólo para el cumplimiento de normas, o alguien revisará activamente los datos acumulados para identificar vulnerabilidades?
- ¿Cuán crítico es que suceda la auditoría?
Qué auditar
Identificar qué se necesita auditar realmente es el desafío más grande al crear una estrategia de auditoría. Entender los datos en sus bases de datos es fundamental para el éxito de su estrategia de auditoría.
Desde una perspectiva lógica, los datos que necesitan ser protegidos, cuyos accesos deberían ser auditados, caen generalmente en estas categorías:
- Datos que pueden ser usados para identificar a una persona, como un número de pasaporte o un número de seguridad social.
- Datos que proveen información personal acerca de una persona, como su cabello y color de ojos, o incluso algo simple como el tipo de películas que le gusta ver.
- Datos que pueden ser considerados sensitivos. Esto básicamente se refiere a información que puede afectar negativamente, o en algunos casos favorablemente, a aquellos involucrados si cayera en malas manos. Esto típicamente incluye información como le registro de salud de una persona o información financiera perteneciente a una compañía o una persona.
Desde una perspectiva de base de datos, estas son las acciones que deberían ser consideradas para la auditoría:
- Inicios de sesión
- Configuración
- Configuración de la auditoría
- Modificación del esquema
- Modificaciones de datos
Hay un balance delicado entre auditar muy poco y auditar demasiado. Esto depende grandemente en sus razones para auditar. Incluso si su primer objetivo debería ser mantener los datos de sus clientes seguros, muchas compañías toman esto sólo hasta seguir las medidas prescritas por las reglas de cumplimiento para su industria específica.
Si usted mide la seguridad de sus datos por su habilidad de pasar su auditoría, entonces de todos modos audite sólo lo que es prescrito, ya que esto es exactamente para lo que son estos requerimientos. Cumplir con las regulaciones de su industria para seguridad debería ya cubrir la mayor parte de las vulnerabilidades.
Como una sugerencia de buena práctica, también audite sus auditorías para asegurar que nadie ha modificado lo que está siendo auditado y que usted está cubierto para todas las eventualidades.
Si usted intenta usar la información obtenida para fortificar su servidor, asegúrese de que también audita los eventos exitosos, así como los fallidos. No solamente le ayudará a determinar quién está abusando de sus privilegios, sino que también le permitirá ver si los ataques fallidos pueden haver sido exitosos después de múltiples intentos. Los ataques SQL son más comúnmente dirigidos al usuario SA, así que si usted ve múltiples intentos de inicio de sesión fallidos para el usuario SA y luego un inicio de sesión exitoso, es válido pensar que alguien ha obtenido acceso no autorizado a su sistema.
Auditando su implementación de auditoría
No es una ocurrencia poco común para DBAs deshabilitar la auditoría si el servidor súbitamente comienza a desempeñarse pobremente.
Cuando esto ocurre, los DBAs pueden olvidar rehabilitar todas las tareas que se han deshabilitado temporalmente, y esto puede luego llevar a una vulnerabilidad incrementada. Auditar su implementación de auditoría puede ayudarle a evadir este problema. Idealmente, una notificación debería ser enviada si cambios han sido hechos a la configuración de auditoría, ya sea como un recordatorio para el DBA para que rehabilite la auditoría o al auditor para hacerle saber que alguien ha modificado la implementación de auditoría.
Esto también resalta cualquier actividad no autorizada realizada por usuarios autorizados que tenían premeditado deshabilitar la auditoría previamente a realizar su actividad.
Auditoría selectiva
En algunos casos, puede ser necesario aplicar auditoría selectiva por usuario o por objetos.
Por ejemplo, la compañía puede querer tener un registro de quién ve sus datos de salarios o un empleado específico ha levantado algunas banderas rojas, y todas sus actividades necesitan ser rastreadas para determinar su culpa o inocencia.
Archivando información de auditoría
Dado el volumen potencial de información auditoría, se volverá necesario archivar los datos. Tener un repositorio central para todos los datos auditados también lo hará más fácil identificar tendencias y procesar la información.
AAdicionalmente, mantener la información de auditoría archivada le permitirá revisar auditorías pasadas de nuevo, a la luz de nuevas transgresiones que puede que hayan sido descubiertas recientemente.
La separación de tareas para asegurar que sólo personal autorizado, lo que excluye administradores de sistema, tiene acceso a la información de auditoría también ayuda a prevenir la modificación de datos de la auditoría.
Características de SQL Server disponibles para facilitar la auditoría de seguridad
SQL Server tiene muchas características para facilitar la auditoría. Dependiendo de sus requerimientos de auditoría, una o una combinación de estas características puede ser la mejor manera de alcanzar su meta.
Auditoría C2
SQL Server has offered C2 auditing since SQL Server 2000 in orSQL Server ha ofrecido auditorías C2 desde SQL Server 2000 para ser clasificado dentro de los criterios de auditoría C2 prescritos por el Departamento de Defensa.
Los eventos auditables incluyen la ejecución de procedimientos almacenados, la creación o eliminación de objetos y actividades de inicio y cierre de sesión. En el caso de la auditoría C2, no es posible elegir qué auditar. Básicamente audita todo o nada.
Los datos de la auditoría C2 son grabados en un archivo de registro en el directorio MSSQL\DATA. Cada archivo está limitado a 200MB y uno nuevo es creado cada vez que ese límite es alcanzado, hasta que al directorio se le acaba el espacio o la auditoría es deshabilitada.
Para habilitar la Auditoría C2, usted puede:
Revisar la casilla Enable C2 audit tracing en la pestaña de seguridad del diálogo de propiedades del servidor.
- Use el siguiente código T-SQL.
123456789sp_configure 'show advanced options', 1;GORECONFIGURE;GOsp_configure 'c2 audit mode', 1;GORECONFIGURE;GO
Un dato importante a notar acerca de la auditoría C2 es que cuando está habilitada y el servidor, por alguna razón, no puede registrar un evento, el servidor se apagará. Esto es para prevenir que tome lugar cualquier actividad que no está siendo auditada.
Cuando esto pasa, sólo hay 2 soluciones al problema.
- Usted necesita hacer algo de espacio en el servidor para que la auditoría pueda continuar antes de reiniciar el servidor o
- Usted necesita reiniciar SQL Server con la bandera –f para evitar la auditoría.
La auditoría C2 será deprecada en una versión futura y será reemplazada con Compatibilidad con Criterio Común.
Compatibilidad con Criterio Común
Compatibilidad con Criterio Común fue introducida en SQL Server 2005 SP1, pero desafortunadamente está disponible sólo en las Ediciones Enterprise, Development y Evaluation de SQL Server.
Compatibilidad con Criterio Común fue creada por un grupo de naciones para lograr lo siguiente:
- Incrementar la disponibilidad de productos de IT con seguridad mejorada
- Ayudar a los usuarios a evaluar productos de IT
- Mejorar la confianza del consumidor en seguridad de productos de IT
Un cuerpo internacional que es reconocido por la Organización Internacional de Estándares (ISO) es responsable de mantener la compatibilidad con criterio común.
Cuando usted habilita las opciones de compatibilidad con criterio común esto es lo que pasará:
- Tomará ligar la Protección de Información Residual. Esto significa que las asignaciones de memoria serán rescritas con un patrón conocido de bits antes de que puedan ser asignadas a un nuevo recurso.
- Los inicios de sesión serán auditados. Esto incluye inicios de sesión exitosos y fallidos.
- Los DENYs a nivel de tabla tomarán precedencia sobre los GRANT a nivel de columna.
Para habilitar la opción de compatibilidad con criterio común usted puede:
Seleccionar la casilla Enable Common Criteria en la pestaña Security en el diálogo Server Properties.
- Usar el siguiente script T-SQL:
123456789sp_configure 'show advanced options', 1;GORECONFIGURE;GOsp_configure 'common criteria compliance enabled', 1;GORECONFIGUREGO
SQL Server Auditing
SQL Server Auditing fue primeramente lanzado en SQL Server 2008 como una característica sólo de la edición Enterprise. En SQL Server 2012, la auditoría a nivel de servidor está también disponible ahora para los usuarios de la Edición Standard.
La característica de auditoría fue diseñada para mejorar una plataforma de auditoría de seguridad con un impacto mínimo en el desempeño, lo cual es fácil de manejar y puede satisfacer todas las consultas de auditoría.
Para usar SQL Auditing, 3 componentes deben ser configurados:
- Auditoría de Servidor (requerido)
La Auditoría de Servidor reside en la base de datos master y es usado para definir dónde se almacenará la información de auditoría, si la auditoría debería ser síncrona o asíncrona, cómo deberían manejarse los archivos, y qué pasa si un evento de auditoría no puede ser registrado.
Esto está disponible en todas las ediciones de SQL Server de 2012 en adelante. - Especificación de Auditoría de Servidor (opcional)
Aquí es donde los eventos a nivel de servidor pueden ser auditados. Para crear una especificación de Auditoría de Servidor, Una Auditoría de Servidor necesita ser creada primero. Una especificación de Auditoría depende de la Auditoría de Servidor y sólo puede haber una Especificación de Auditoría por Servidor por cada Auditoría de Servidor. Las especificaciones de Auditoría de Servidor le permiten auditar cosas como inicios de sesión exitosos hecho al servidor, acciones DBCC, etc.
Esto también está disponible en todas la Ediciones de SQL Server de 2012 en adelante.. - Especificación de Auditoría de la Base de Datos (opcional)
La especificación de auditoría de la Base de Datos también depende de la auditoría del servidor. Permite una auditoría más granular dentro de la base de datos, incluyendo acciones realizadas en objetos específicos como qué usuario realizó un SELECT en una tabla específica. Múltiples especificaciones de auditoría de base de datos pueden ser enlazadas a una sola Auditoría de Servidor.
La información grabada en los registros de transacciones puede ser leída usando la función fn_get_audit_file, como se indica a continuación.
|
1 |
SELECT * FROM fn_get_audit_file('D:\Audits\*',default,default) |
Seguimiento de SQL
Actualmente, Seguimiento de SQL es aún el método preferido para realizar auditoría en SQL Server, ha estado presente desde SQL 2000 y la mayoría de los DBAs están familiarizados con él, o al menos con usar Profiler..
Seguimiento de SQL usa un conjunto de procedimientos almacenados que graban eventos que han sido identificados en la definición de seguimiento. Los seguimiento son altamente configurables y pueden lograr una auditoría muy granular.
SQL Server provee Profiler como una interfaz para Seguimiento de SQL, lo cual hace fácil crear seguimientos y correrlos. Desafortunadamente, Profiler viene con algunos costos de desempeño y como tal no es siempre una buena idea correrlo contra su servidor de producción.
Si usted necesita correr seguimientos contra su servidor de producción, hágalo usando sentencias Transact-SQL para manera y correr los seguimientos. Los siguientes son los procedimientos que pueden ser usados para crear y leer información de seguimiento:
- sp_trace_create
Este procedimiento es usado para crear una definición de seguimiento. Las opciones de seguimiento como sustitución incremental de archivos y apagado del servidor, y la localización de los archivos de seguimiento puede también ser especificado aquí. - sp_trace_setevent
Este procedimiento es usado para definir qué eventos de seguimiento desearía capturar y qué columnas de cada evento se grabarán. - sp_trace_setstatus
Dado que todos los seguimiento son creado en un estado parado, este procedimiento requiere iniciar el seguimiento y luego pararlo de nuevo. Puede también ser usado para recomer completamente el seguimiento. - CREATE EVENT SESSION
Este comando crea una sesión de evento y le permite especificar los eventos, acciones y objetivos que deberían ser asociados a la sesión. Usted puede ver los eventos disponibles, las acciones y objetivos seleccionando sys.dm_xe_objects con los tipos de objeto de evento, acción y objetivo respectivamente. - ALTER EVENT SESSION
Este comando es usado para modificar la configuración de sesiones de evento y para iniciar o parar la sesión de evento. - DROP EVENT SESSION
Este comando es usado para prescindir de una sesión de evento cuando ya no es requerida. - sys.sp_cdc_enable_db
Este comando habilita CDC para usarse en una base de datos específica, y es requerido antes de que cualquier tabla pueda ser habilitada para CDC. - sys.sp_cdc_enable_table
Este comando habilita CDC en una tabla específica. Esto crea una instancia de captura asociada de la tabla, incluyendo una tabla de cambios y funciones de consulta. Las primeras 5 columnas en la tabla contienen Metadatos a ser usados por el proceso CDC y el resto de las columnas están basadas en las columnas en la tabla fuente a ser capturada. - CREATE TRIGGER
Esta sentencia puede ser usada para crear un desencadenador ya sea DML, DDL o de Inicio de Sesión. Cuando se crea un desencadenador DDL, especificar el alcance del desencadenador como ON ALL SERVER u ON DATABASE es requerido. - ENABLE/DISABLE TRIGGER
Los desencadenadores son habilitados por defecto cuando son creados. Estos comandos le ayudan a deshabilitar un desencadenador sin removerlo de la base de datos y luego rehabilitarlo más tarde. Usted también puede deshabilitar desencadenadores DML usando el comando ALTER TABLE. - SQL Server Common Criteria Certifications
- Auditing in SQL Server 2008
- Using SQL Server 2008 Extended Events
- Definición y descripción general interbloqueo de SQL Server - December 16, 2019
- 5 consejos prácticos de Transact-SQL que puede usted conozca (o no) - December 24, 2016
- Creando una estrategia de auditoría exitosa para sus bases de datos SQL Server - October 29, 2016
Una cosa a notar acerca de los seguimientos es que no son persistentes. Si su instancia es reiniciada, el seguimiento no será recreado automáticamente.
Seguimiento de SQL será deprecado en futuras versiones de SQL Server y será reemplazado con Eventos Extendidos.
Eventos Extendidos
Eventos extendidos fueron introducidos en SQL 2008, es un marco de trabajo de eventos altamente configurable, que ultimadamente reemplazará a Seguimiento de SQL. En SQL 3008, los eventos disponibles en el motor de eventos extendidos eran limitados, pero en SQL Server 2012 todos los eventos que están disponibles en Seguimiento de SQL, lo están también ahora en Eventos Extendidos.
El motor de eventos extendidos tiene una carga en el desempeño muy baja, lo cual lo hace preferible a Seguimiento de SQL. El motor sólo maneja los paquetes que contienen la información del evento, haciéndolo extremadamente flexible. También es posible correlacionar la fecha entre aplicaciones, SQl Server y Windows usando Eventos Extendidos.
SQL Server 2012 también introduce una interfaz de usuario para eventos extendidos, lo cual lo hace mucho más fácil usar sin tener que entender la arquitectura interna del marco de trabajo de Eventos Extendidos. El asistente de eventos extendidos puede ser encontrado debajo del nodo de administración de su servidor.
El asistente le guiará a través de la creación de una nueva sesión usando una plantilla existente o le ayudará a crear la suya propia seleccionando los eventos y campos de eventos que requiere.
Alternativamente, usted puede usar Transact-SQL para crear seguimientos. Los siguientes son tres comandos principales para crear y manejar Sesiones de Eventos Extendidos:
Captura de Datos Modificados
Captura de Datos Modificados fue introducida en SQL Server en 2008. Esta característica disponible sólo en la edición Enterprise provee información prácticamente en tiempo real, con poco impacto en el desempeño, acerca de cambios DML lo cuales pueden ser usados para propósitos de auditoría.
Esta característica recolecta el registro de transacciones de SQL Server como parte del proceso de sp_replcmds, para cambios a datos en las tablas para las cuales fue habilitada. CDC depende de SQL Server Agent, el cual debe estar corriendo todo el tiempo para asegurar que la captura de datos toma lugar. Dos trabajos son creados cuando CDC es implementado, uno es usado para capturar los datos y poblar las respectivas tablas, y por otro lado es usado para realizar la limpieza.
La captura de datos modificados puede ser habilitada en su base de datos y tablas específicas, sin tener que hacer ningún cambio a los objetos en sí mismos.
Los siguientes comandos pueden ser usados para implementar CDC:
Desencadenares DML, DDL y de Inicio de Sesión
Los desencadenadores pueden ser usados para inicios de sesión o cambios a objetos y datos dentro de su base de datos.
Los desencadenadores DML se activan en respuesta a sentencias INSER, UPDATE y DELETE, mientras que los desencadenadores DDL se activan en respuesta a cambios hechos a la definición de los datos como CREATE, DROP, ALTER, etc. Los desencadenadores de Inicio de Sesión se activan cada vez que un usuario ingresa a SQL Server, lo cual puede ser usado para auditar accesos a su servidor. Desafortunadamente, el desencadenador no se activa si el usuario no está autenticado, y como tal sólo será útil auditando inicios de sesión exitosos.
Para usar desencadenadores DML para auditar cambios de datos, los desencadenadores necesitarán ser añadidos a cada tabla que desea auditar. Esto puede ser incómodo y difícil de mantener. Las aplicaciones desarrolladas en SQL Server a menudo hacen uso de desencadenadores DML para auditoría interna.
De la misma manera, los desencadenadores DDL pueden ser implementados para grabar cualquier cambio a los objetos de la base de datos. Los desencadenadores DDL son creados a nivel de la base de datos o el servidor y se activan cuando el evento específicamente configurado ocurre.
Las siguientes Sentencias Transact-SQL pueden ser usadas para crear o mantener desencadenadores DML o DDL.
Conclusión
Tan tentador como sea auditar todo lo que pasa en su servidor, la clave para una estrategia de auditoría exitosa es conocer sus datos, entender qué necesita ser auditado, tener procesos para asegurar que los datos de auditoría son revisados y que cuando las vulnerabilidades son identificadas, son atendidas y contramedidas son implementadas.
La mejor estrategia es una estrategia a medida de su negocio, que audita no sólo la información prescrita por su autoridad industrial, sino que también todo lo que usted necesita para identificar las amenazas internas y externas a la seguridad de su información sensitiva, mientras que se toma en cuenta el desempeño, el cumplimiento de requerimientos, así como su espacio de almacenamiento disponible.
Con el gran número de características provistas por SQL Server para ayudarle a implementar la estrategia de auditoría perfecta, asegurar los datos sensitivos de su negocio y clientes nunca ha sido más fácil. Aunque algunas características como SQL Audit son aún algo jóvenes y no completamente desarrolladas, la correcta combinación de características le ayudará a caminar en la cuerda floja entre el cumplimiento de requerimientos, el desempeño, los requerimientos de almacenamiento y la seguridad.
Referencias
Ella es una creyente firme en el aprendizaje durante toda la vida y es una expositora regular en grupos de usuarios de SQL Server, compartiendo su pasión y conocimiento con cualquier persona que escuche.
Ver todas las entradas de Minette Steynberg