Cómo mejorar la seguridad de tu SQL server

Descubre cómo mejorar la seguridad de tu SQL Server 2022 desplegado sobre Microsoft Windows Server a través de las mejores prácticas para asegurar tus datos y tener una arquitectura resiliente y lo más segura posible.

NOTA: Es importante decir que todo lo aquí descrito está preparado para entornos de SQL Server sobre Windows Server, aunque algunas de las recomendaciones serán operativas también para sistemas GNU/Linux.

Además de lo aquí expuesto, se recomienda revisar el artículo Requisitos y planificación de la instalación de SQL Server 2022 dentro de nuestro blog, aunque algunas partes, como las relativas a la seguridad, serán algo redundantes.

Consejos y mejores prácticas para asegurar nuestro SQL Server:

Lo primero que deberemos tener en cuenta es que, cuando hablamos de seguridad, nunca hay la suficiente. Siempre tenemos que hablar de un modelo de capas de cebolla en el que vamos implementando distintos niveles de protección.

Esos niveles de protección deben tener una aplicación holística, o lo que es lo mismo, aplicarse a todos los niveles y aspectos de la instalación del servidor de base de datos: desde la instalación física del servidor a los parches de seguridad de los aplicativos y sistema operativo o a la forma en la que se diseñan las consultas.

A continuación, vamos a revisar algunos de los puntos a tener en cuenta para mejorar la seguridad de nuestra base de datos Microsoft SQL Server sobre sistemas Microsoft Windows Server.

Seguridad física:

El primer punto de la seguridad de un sistema, antes de centrarnos en la parte lógica, debe ser asegurar la máquina física que contiene el servidor. Por mucho que protejamos un servidor a nivel lógico, por mucho que pongamos firewalls, antivirus, lo parcheemos, configuremos sus accesos, etc., si después no hay una seguridad física, una puerta que evite el acceso al servidor, un control de acceso, un control de temperatura, etc., todo lo anterior no servirá de nada porque alguien podrá llegar hasta el servidor y apagarlo, llevárselo, etc.

La seguridad física del servidor puede comprender gran cantidad de elementos, los cuales incluyen tanto el que los servidores estén en una sala aparte con acceso controlado (mediante una puerta con cerradura, con cerradura electrónica, sistemas biométricos, etc.) como el contar con sistemas de extinción de incendios, sistemas de aire acondicionado para mantener la temperatura estable y evitar problemas de sobrecalentamiento de los servidores, etc.

Aunque no forma parte de la seguridad física, se deben tener en cuenta también otras “facilities” como las fuentes de alimentación redundantes, los sistemas de soporte eléctrico ininterrumpido (SAI), la acometida desde distintos proveedores, la conexión a internet (preferentemente redundante), etc.

Seguridad del sistema operativo:

Este es un punto del que no me canso de hablar. Si no tenemos un sistema operativo fuerte, es imposible que tengamos un aplicativo que se esté ejecutando sobre este y que sea seguro.

Antes de nada, diremos que es imprescindible desplegar únicamente los servicios mínimos sobre el servidor y que lo deseable es no desplegar más de uno por servidor, haciendo uso de máquinas virtuales, containers, etc. De esta manera, se evitará la posibilidad de crear puntos críticos de fallo en nuestra infraestructura. Por supuesto, en el caso de las bases de datos se deben desplegar en un servidor aislado que no dé más servicio que ese.

Debemos aplicar todos los packs de parches y actualizaciones posibles sin dejar ninguno, pero teniendo plenamente claro que instalamos solo los que se aplican a nuestra plataforma.

Con esto quiero decir que, si no tenemos un hardware en concreto, puede ser contraproducente aplicar un parche creado para ese hardware, y que si hay un parcheo para Office y nosotros no tenemos Office instalado, será mejor no instalarlo porque puede que el mismo parche tenga algún bug, problema, etc.

Recordemos que lo deseable sería desplegar un entorno de pruebas sobre el que desplegar nuestras actualizaciones y probarlas antes de llevarlas a producción.

Por supuesto, además de las actualizaciones, debemos instalar algún software de antivirus y antimalware que nos proteja de las mil y una amenazas existentes hoy día y que no paran de mejorar y aflorar continuamente.

Por último, no debemos olvidar el firewall del sistema operativo, que debe tener únicamente los puertos mínimos abiertos para poder operar. Para revisar este punto, recomendamos consultar el tutorial donde se puede ver cómo realizar la configuración de los puertos requeridos por el SGBD. Así mismo, recomendamos revisar el siguiente contenido de la web de Microsoft para aprender a configurar el servicio SSIS con el firewall de Windows.

A continuación, vamos a revisar algunas de las recomendaciones para mejorar la seguridad de nuestro SQL Server.

Seguridad de los archivos de SQL Server:

SQL Server utiliza el sistema de ficheros del sistema operativo para almacenar algunos ficheros. Para evitar problemas, se deben limitar los accesos a estos ficheros. Para ello, deberemos determinar las rutas a proteger, y lo primero que debemos hacer es lanzar la siguiente sentencia desde SSMS:

SELECT CONVERT(char(20), SERVERPROPERTY(‘productlevel’));

NOTA: En nuestro caso estamos trabajando con SQL Server 2022, por lo que es una 16.x, pero explicamos esto para aquellos que tengan otras versiones.

Pudiendo obtener como resultado:

Cuando sepamos la versión de nuestro SQL Server, podremos sustituir la versión en la cadena “<unidad>:\Archivos de programa\Microsoft SQL Server\nnn\”.

Donde:

• <unidad>: será la letra de unidad donde está SQL Server instalado, por ejemplo “E:”.
• nnn: Identifica la versión de SQL Server.

Sobre todo esto, además, hay que tener en cuenta que en función de la instalación se tendrán distintos elementos y nomenclaturas.

• MSSQL: Motor de SQL Server. Irá seguido de un número de versión, un guion bajo y la versión secundaria, un punto y el nombre de instancia. Como por ejemplo: MSSQL{nn}.MSSQLSERVER.
• MSAS: Analysis Services. Irá seguido de un número de versión, un guion bajo y la versión secundaria, un punto y el nombre de instancia. Como por ejemplo: MSAS{nn}.MSSQLSERVER.
• MSRS: Reporting Services. Irá seguido del número de versión, un guion bajo y la versión secundaria, un punto y el nombre de instancia. Como por ejemplo: MSSQL{nn}.<instancia>.

Dicho todo esto, se podría concretar que, para una instancia llamada “PruebaNacho”, las rutas quedarían de la siguiente manera:

• C:\Archivos de programa\Microsoft SQL Server\MSSQL16\
• C:\Archivos de programa\Microsoft SQL Server\MSAS16.PruebaNacho\
• C:\Archivos de programa\Microsoft SQL Server\MSRS16.PruebaNacho\

Seguridad de SQL Server en el registro del sistema:

De la misma manera que se protegen las rutas de los ficheros del sistema operativo en lo relativo a SQL Server, se deben proteger las entradas del SGBD dentro del registro de Windows (accesible con RegEdit).

Teniendo clara la versión, se deben proteger las siguientes entradas del subárbol del registro que se crean en “HKLM\Software\Microsoft\Microsoft SQL Server<instancia>”.

Siendo un ejemplo de ello para nuestra instancia “PruebasNacho”:

• HKLM\Software\Microsoft\Microsoft SQL Server\MSSQL16.PruebaNacho
• HKLM\Software\Microsoft\Microsoft SQL Server\MSAS16.PruebaNacho
• HKLM\Software\Microsoft\Microsoft SQL Server\MSRS16.PruebaNacho

Configuración del motor de base de datos de SQL Server para el cifrado de conexiones:

Para asegurar la plataforma, es necesario cifrar todas las conexiones entrantes a Microsoft SQL Server, siendo también posible habilitar el cifrado solo para un conjunto específico de clientes, que a nuestro modo de ver es menos seguro que obligar al cifrado de todos.

Para configurar este cifrado, lo primero que se debe configurar es SQL Server para usar un certificado que dé cumplimiento a los requisitos del certificado para SQL Server, lo cual permitirá continuar con el resto de los puntos necesarios para poder dotar la infraestructura del SGBD de una seguridad adicional.

En este artículo no queremos extendernos demasiado, por lo que preferimos remitir al lector a la revisión del siguiente enlace de Microsoft, donde podrá ver cómo configurar SQL Server para el uso de certificados y cómo cambiar la configuración de cifrado de la instancia de SQL Server, permitiendo con estos dos pasos el cifrado de todas las conexiones entrantes a SQL Server cuando se usa un certificado de una entidad comercial pública.

Cambio de las cuentas usadas por los servicios:

Otro punto bastante simple y fácil de implementar es el cambio de las cuentas usadas para la autenticación de SQL Server por parte de los servicios. Esto es más que necesario, tanto para cambiar las contraseñas, que no debería ser un problema ya que deberían ser únicas, sino también para cambiar los nombres de usuario y que no sean genéricos, lo cual incrementará notablemente la seguridad.

Para poder cambiarlas se debe acceder al administrador de configuración de SQL Server que podremos acceder, o bien desde el propio ejecutar de Windows, o ejecutando directamente la consola con “C:\Windows\SysWOW64\SQLServerManager<nn>.msc”, sustituyendo <nn> por la versión de SQL Server instalada.

Cabe recordar que, dentro de este mismo artículo, en la sección “Seguridad de los archivos de SQL Server”, se explica como obtener la versión de SQL Server que se está implementando, siendo por ejemplo la 16 para un SQL Server 2022 y quedando la siguiente ruta “C:\Windows\SysWOW64\SQLServerManager16.msc”.

NOTA: Cuando se haga un cambio de contraseña desde el administrador de configuración de SQL Server, los cambios toman efecto sin requerir un reinicio del servicio.

Enmascaramiento dinámico de datos:

El uso de enmascaramiento dinámico de datos también conocido como DDM en base a su acrónimo inglés (Dynamic Data Masking) proporciona una capa adicional de protección mediante la limitación de acceso a la información por parte de usuarios no privilegiados.

NOTA: EL DDM está disponible desde la versión SQL Server 2016.

Este es un modelo que añade una buena seguridad con una mínima necesidad de diseño.

El enmascaramiento dinámico de datos permite que los clientes especifiquen la cantidad de información que debe estar disponible para su consulta y a quien se permite acceder.

Una de las ventajas de DDM es que se puede aplicar sobre los campos que no quieren que se exfiltren, pudiendo mostrarse otros datos de esa misma tabla pero impidiendo el acceso a las columnas concretas.

Para la implementación de DDM, se necesita designar una directiva de enmascaramiento de datos central, que debe actuar sobre los campos confidenciales de la base de datos. A continuación, se deben designar los usuarios (pueden ser roles) con acceso a la información, siendo estos los únicos que podrán acceder a la información, denegándose el acceso al resto de roles y usuarios.

Para configurar el enmascaramiento dinámico de datos haremos uso de comandos de T-SQL, pero deberemos tener en cuenta tanto una sintaxis concreta como una serie de limitaciones en su uso.

Para comenzar, debemos saber que no se puede hacer uso de DDM sobre los siguientes tipos de columnas.

• Columnas cifradas.
• Filestream.
• Column_Set.
• Columna de tabla externade PolyBase.
• Columnas de índice FULLTEXT.

Hay que tener en cuenta también que no se pueden crear mascaras en columnas calculadas, pero si para el cálculo de una columna se hace uso de una columna enmascarada, la resultante estará enmascarada.

Los permisos necesarios para crear una DDM son los de CREATE TABLE y ALTER, mientras que para la modificación, agregación, reemplazo o eliminación se requieren los permisos ALTER ANY MASK y ALTER TABLE. Por último, la visualización se hará con SELECT como cualquier otra consulta, pero dependerá de la posibilidad de acceso a la misma.

Para aprender más sobre esta opción recomendamos visitar la web de Microsoft.

Protección ampliada para el motor de base de datos:

SQL Server tiene una característica de seguridad que curiosamente no está activada por defecto, sino que el administrador es el que tiene que ponerla en funcionamiento. Se trata de la protección ampliada para la autenticación.

Esta, es una característica de los componentes de red que implementa el sistema operativo y que permite realizar conexiones más seguras cuando las conexiones se realizan con Extended Protection.

Esta función usa el enlace de servicio y el enlace de canal para la prevención de ataques de retransmisión de la autenticación, en los que un cliente que puede realizar la autenticación NTLM conecta a un atacante cuando el atacante usa las credenciales del cliente para hacerse pasar por este y autenticarse en un servicio.

Para habilitar esta función se deberá ir al “Administrador de configuración de SQL Server”, expandir la configuración de red de SQL Server y acceder a las propiedades de “Protocolos de _<instancia>” donde <instancia> será el nombre de la instancia a configurar.

Una vez ahí, se debe buscar el valor “Protección ampliada” dentro de las opciones avanzadas pudiendo marcar que fuerce el cifrado.

Para que los cambios tomen efecto se deberá reiniciar la base de datos.

Revisión de la cuenta SA:

La cuenta SA es una vieja conocida de los administradores de SQL Server y ha generado más de una discusión entre estos y los administradores de sistemas operativos. Esta cuenta es usada para el inicio de sesión del propio motor de la base de datos de SQL Server, tiene acceso con privilegio de administrador de sistema.

Se trata de una cuenta creada de manera predeterminada en el servidor mientras se despliega la instancia predeterminada del máster. Es importante saber que los privilegios no pueden limitarse, pero si puede deshabilitarse.

Lo mejor, sería hacer que se use la autenticación de Windows, que hará que la autenticación de SQL Server no esté habilitada. Esto significa que la cuenta de SA estará presente pero deshabilitada, presentando una contraseña creada de manera aleatoria y con gran complejidad.

Limitación del usuario invitado (guest) de SQL Server:

Todas las bases de datos SQL Server, igual que otros aplicativos, incluyen un usuario invitado, también conocido como guest. Los permisos que posee este usuario se aplican a todos los usuarios que tienen acceso a la base de datos sin disponer de una cuenta propia.

Esta cuenta no se puede eliminar (quitar), pero si que puede ser deshabilitada revocando su permiso de conexión.

NOTA: Puede usarse el comando T-SQL “REVOKE CONNECT FROM GUEST;” en las bbdd que no sea master ni tempdb.

Explotación del canal lateral:

Los sistemas informáticos requieren de soportes físicos para mantenerse operativos, y esto desemboca en la generación de todo tipo de huellas, como por ejemplo tiempo, imagen, sonido, etc.

La vulnerabilidad de canal lateral explota alguna de esas huellas para obtener información sensible gracias a un algoritmo. Usando para ello patrones de salida de información que los ordenadores emiten constantemente.

Para minimizar el riesgo de un ataque de canal lateral a un sistema SQL Server se pueden tener en cuenta los siguientes puntos:

• Mantener el sistema lo más actualizado posible (si, soy muy pesado con esto, lo sé).
• No olvidar las actualizaciones de firmware más recientes para cualquier hardware local.
• Si se trabaja con nube pública, se debe agregar protección adicional contra ataques de canal lateral con máquinas virtuales aisladas, hosts dedicados o mediante el aprovechamiento de máquinas virtuales de proceso confidencial.
• En el caso de la nube privada, disponemos de opciones como máquinas virtuales blindadas de Microsoft Hyper-V.

Protección frente a SQL injection:

SQL injection, “inyección SQL” o “SQLi” es una vulnerabilidad de seguridad de los servicios web que permite que un atacante modifique las consultas que llegan a la base de datos desde una aplicación.

Los atacantes suelen usar esta vulnerabilidad para exfiltrar datos que normalmente no podría recuperar, incluyendo datos pertenecientes a otros usuarios o cualquier otro dato al que la propia aplicación pueda acceder.

En los casos más críticos, el atacante será capaz de modificar o incluso eliminar los datos contenidos dentro de la base de datos, provocando por tanto cambios persistentes en el contenido y el comportamiento de la aplicación.

Para minimizar el riesgo de una inyección SQL, se deberían tener en cuenta los siguientes puntos:

• Construir las instrucciones SQL generadas dinámicamente de forma parametrizada.
• Tanto los administradores de seguridad como los developers, deben revisar todo el código que llama a EXECUTE, EXEC o “sp_executesql”.
• Revisar los procesos que construyan instrucciones SQL.
• Validar siempre las entradas de usuario.
• Limpiar las salidas de error de que se desbordan.

Además de lo anteriormente expuesto, no se deben permitir los siguientes caracteres de entrada:

• “;” Delimitador de consultas.
• “’” Delimitador de cadena de datos de caracteres.
• “—“ Delimitador de comentario de una sola línea.
• “/ * … * /” Delimitadores de comentario.
• “xp_” Procedimientos almacenados extendidos por el catálogo como por ejemplo “xp_cmdshell”.

Se debe sustituir “xp_cmdshell” por “SQLCLR” ya que se desaconseja su uso en entornos SQL Server.

Autenticación de Windows para Reporting Services:

El sistema operativo es el encargado de administrar la autenticación de los usuarios para el uso de Reporting Services a través de la seguridad integrada, haciendo la validación de las credenciales de los usuarios.

Esto no siempre tiene porque ser así, y podemos desarrollar la autenticación personalizada dentro de Reporting Services para admitir esquemas de autenticación adicionales a través de la interfaz de extensión de la seguridad conocida como “IAuthenticationExtension2”.

Para aprender como tomar ventaja de esta funcionalidad, recomendamos visitar el siguiente recurso de Microsoft.

Auditoría del sistema y de las bases de datos:

Mantener informes frecuentes de los aplicativos y del propio sistema operativo, así como las auditorías, nos ayudarán a tener un sistema seguro. Por esta razón, se deben crear directivas de auditoría a nivel del servidor, así como a nivel de la base de datos.

Cuando se creen las auditorías, no se deben olvidar ni las tablas, ni las columnas con datos confidenciales a los que se esté aplicando cualquier tipo de medida de seguridad.

Además de crearse las reglas y los informes, estos deben ser, como es lógico, revisados de vez en cuando para constatar que todo va bien, y desencadenar las operaciones pertinentes en caso de encontrar algún problema.

A continuación, se puede leer más información sobre la auditoría de SQL Server en la web de Microsoft.

Las contraseñas seguras:

A lo largo de este artículo, y de tantos otros escritos previamente y que escribiremos a posteriori, hablamos de la necesidad de utilizar contraseñas seguras, y no quiero cerrar este artículo sin responder, o aproximarme a la respuesta de la siguiente pregunta ¿Qué es una contraseña segura para Microsoft?

Bueno, lo primero que hay que decir es que esto depende un poco de los requisitos que se marquen desde el dominio o desde el aplicativo usado para validar, y que, además, dada la potencia de los equipos y utilidades encaminadas a romper las contraseñas, cada día se necesita ampliar el número de caracteres usados, pero en líneas generales, podemos decir que una buena contraseña debería:

• Tener una longitud no inferior a ocho
• No estar compuesta por el nombre de la organización, un nombre de usuario, ni el nombre de la persona.
• No estar compuesta por ninguna palabra existente en un diccionario.
• No tener similitud con contraseñas anteriores.
• Contener mayúsculas.
• Contener minúsculas.
• Contener números.
• Contener caracteres especiales.

Conclusión

A lo largo de este artículo se han revisado algunas de las mejores prácticas para mantener nuestro Microsoft SQL Server 2022 (u otras versiones) seguro. Los consejos que aquí se dan realmente son útiles para todas las versiones soportadas en la actualidad, incluyendo tanto on-premise como on-cloud.

Hemos repasado algunos puntos sobre la seguridad física, algunos sobre codificación, consulta e incluso programación, y otros relacionados con la administración, sobre todo en la parte de procesos y usuarios.

Todos estos puntos irán encaminados a mejorar la seguridad, pero hemos de decir que lo mas importante, como hemos dicho en otras ocasiones, es disponer de una correcta planificación, que nos ayudará a eliminar la mayor parte de las vulnerabilidades o errores de despliegue.

Este artículo, como es lógico, no es (ni debe ser) infinito, ya que terminaría aburriendo y abrumando y por tanto desmotivando al lector. Por eso hemos dejado de lado algunos puntos como por ejemplo el uso de funciones criptográficas de Transact-SQL que quizá abordemos más adelante.

Creemos que, con estos consejos, podrás mejorar la seguridad de tus bases de datos, pero recuerda que estos son solo algunos de los puntos, y te animamos a investigar y añadir nuevos puntos.

¡Gracias por acompañarnos!