Problemas y soluciones de seguridad con SQL Server

Seguridad física

A la hora de definir la seguridad de un sistema SQL server la primera consideración obvia es la seguridad física de la máquina servidora SQL, a menudo se pasa por alto. No se trata simplemente si la máquina puede ser robada o no, sino también de la disponibilidad del acceso físico al sistema de almacenamiento de los archivos de base de datos, los discos de backup, o cualesquier servidor que aloje copias redundantes de la base de datos. Sólo aquellas personas con una necesidad real de tocar físicamente estos sistemas deben tener acceso a ellos; cualquier persona que necesite acceso temporal debe ir acompañado y supervisado.

Una consideración menos obvia es la seguridad son los terminales de las personas que tienen acceso o altos privilegios en SQL Server. Si alguien tiene acceso al administrador de sistemas de SQL Server y deja su escritorio desbloqueado, toda la seguridad no va a evitar que alguien fuera de supervisión acceda a datos potencialmente sensibles. Un problema más insidioso sería si alguien utilizó el escritorio para cambiar alguna instancia de datos o algún dato de forma inadvertida o intencionada y no somos capaces de darnos cuenta del cambio.

Seguridad de red

A pesar de que los servidores pueden ser físicamente inaccesibles, lo más probable es que estén conectados a una red de algún tipo. Podría ser una empresa aislada con una LAN sin conexiones externas, o podría ser una conexión directa a Internet. No importa cuál sea la situación, hay algunas cosas que hay que considerar:

Hay que asegurarse de que el servidor de Windows tiene configurada la seguridad de red adecuada y decidir qué protocolos de red se implementarán para permitir o desactivar los accesos que no sean necesarios.

Asegúrarse que haya un cortafuegos y configurarlo para permitir el acceso a SQL Server. Decidir si desea cifrar las conexiones a SQL Server y configurar el acceso adecuadamente.

Si se utiliza Kerberos, registrar un nombre principal de servidor. Decidir si desea utilizar el servicio Explorador de SQL Server para ayudar a los clientes a encontrar las instancias de SQL Server instaladas, y decidir si desean ocultar algunos casos. Ocultar una instancia implica que las aplicaciones cliente y los usuarios tendrán que conocer los detalles de la conexión de la instancia de SQL Server, esto no impide que la gente busque instancias de SQL Server.

Minimizar las oportunidades de ataque

Cuantos más servicios y funciones que estén habilitadas hay más oprtunidades para atacar el sistema. Con SQL Server 2005 se puso en estado  "off por defecto" por lo que las características de acceso con implicaciones de seguridad están desactivados por defecto y sólo serán habilitadas por el DBA cuando sea necesario. (Este proceso de habilitar y deshabilitar los servicios que comúnmente se llama surface area configuration.) 

Un buen ejemplo de función que es posible que se desee deshabilitar es xp_cmdshell, que proporciona una manera de ejecutar comandos desde el sistema Windows dentro del contexto de una instancia de SQL Server. Si un intruso dispone de privilegios elevados puede comprometer la instancia de SQL Server, también se puede utilizar xp_cmdshell para obtener acceso al sistema de Windows.

Hay una serie de métodos para establecer la surface area configuration.  el Administrador de configuración de SQL Server para la configuración de servicios y protocolos de red. Tambien podemos establecer esta configuración con el procedimiento almacenado sp_configure. A modo de ejemplo, este código desactivará la función xp_cmdshell:

-- Permitir opciones avanzadas para ser cambiados

EXEC sp_configure 'show advanced options', 1;

GO

-- Para actualizar el valor configurado actualmente para - opciones avanzadas

RECONFIGURE;

GO

-- Para deshabilitar xp_cmdshell

EXEC sp_configure 'xp_cmdshell', 0;

GO

-- Para actualizar el valor configurado actualmente para esta - función

RECONFIGURE;

GO

Para más información se puede consultar 

Administrar servidores mediante administración basada en directivas

Cuentas de servicio 

SQL Server se ejecuta como uno o más servicios de Windows, y cada servicio tiene que tener una cuenta de Windows que se utiliza para ejecutarlo. La cuenta debe tener acceso a varios recursos en el sistema Windows (tales como la red y varios directorios del sistema de archivos). Lo más recomendable es que la cuenta tenga los privilegios mínimos posibles necesarios para permitir que SQL Server funcione correctamente. Esto es parte de lo que se llama el principio de mínimo privilegio, que establece que un sistema puede hacerse más seguro a través de la concesión de un usuario o proceso sólo con los permisos requeridos y nada más.

Como tal, una cuenta de servicio de SQL Server no debe ser una cuenta de altos privilegios (como administrador local) porque si SQL Server se ve comprometido, existe la posibilidad de que el sistema Windows también esté en peligro. Si SQL Server requiere el acceso a otros recursos de dominio, se debe crear una nueva cuenta de usuario de dominio con los privilegios mínimos y accesos requiera de recursos. 

Restricción de uso de privilegios del administrador

La mayor exposición a entradas inadecuadas en el sistema se produce con el usuario sa o la función de servidor sysadmin. Hay algunas buenas prácticas a seguir.

Reducir al mínimo el número de personas que tienen acceso a la cuenta sa y restringir el número de miembros de la función sysadmin de modo que sólo aquellas personas que realmente necesiten privilegios de administrador de sistemas los tiengan. No revelar la contraseña de sa a cualquiera que necesite acceso temporal a SQL Server o a un usuario de SQL que quiera realizar alguna tarea rápida. En estas situaciones, es mejor crear una nueva sesión de SQL y concederle privilegios para lo que se requiera.

Es mejor tener personas como miembros de la función sysadmin en lugar de utilizar la cuenta sa. De esta forma, se puede quitar de inicio de sesión de un usuario sin tener que cambiar la contraseña de la cuenta sa. Si hay que hacerse cargo de un servidor viejo y no se sabe quien tuvo acceso a él antes, cambiar la contraseña de sa.

Una cuestión que provoca el debate es si se debe quitar el grupo de Windows BUILTIN / a los administradores de la función sysadmin (se agrega de forma predeterminada). Puede darse el caso de que un administrador de Windows sea capaz de consultar las  bases de datos.  Si se decide quitarlo, hay que tener cuidado. En un entorno agrupado si no se toman las medidas correctas, puede que el servidor de SQL Server no se inicie. 

Para aquellos que tengan acceso al administrador de sistemas, animarlos a no iniciar sesión con privilegios elevados a menos que sea absolutamente necesario. Una buena práctica es  dar a cada uno usuario dos inicios de sesión, uno con privilegios y otro no.  Y utilizar la cuenta con menos privilegios de forma predeterminada ayudando de este modo a minimizar la posibilidad de errores, también reduce la probabilidad de que un terminal de Windows desbloqueado tenga una ventana con privilegios de administrador de sistemas abiertos en él.

Evitar tener aplicaciones que requieran privilegios de administrador de sistemas. Por desgracia, esta es una práctica común e inevitable con algunas aplicaciones, pero se debe evitar esta práctica en aplicaciones de producción propia, es necesario advertir a los desarrolladores que realicen aplicaciones que requieran los mínimos privilegios para acceder al servidor.

Autenticación 

Hay dos modos de autenticación disponibles: Autenticación de Windows y de modo mixto (que es la autenticación de Windows en combinación con la autenticación de SQL Server).

Autenticación de Windows utiliza cuentas de red / dominio validar la cuenta de Windows que se utiliza para conectarse a SQL Server. Si se selecciona esta opción durante la instalación, la cuenta sa se crea con una contraseña generada al azar, pero efectivamente deshabilitada. Inmediatamente después de la instalación, se debe cambiar la contraseña de sa a una contraseña fuerte y segura.

La autenticación de SQL Server se basa en que cada usuario tiene una cuenta de SQL Server definida y la contraseña almacenada en SQL Server. Y, por supuesto, esto significa que la cuenta de sa está habilitada y debe tener una contraseña definida. Con la autenticación de SQL Server, los usuarios tienen al menos dos nombres de usuario y contraseñas (uno para la red y otro para SQL Server). En general se recomienda que sólo se utilice la autenticación de Windows siempre que sea posible, ya que es una solución más segura. 

Si se usa la autenticación de SQL, todos los usuarios deben tener una contraseña, y que sea suficientemente compleja como para ser segura. Esto es especialmente importante para las cuentas de altos privilegios, como sa y los miembros de la función sysadmin. 

Autorización

Uno de los principios de protección de los sistemas es utilizar el principio del mínimo privilegio. Un usuario en una base de datos no debe ser capaz de acceder a los datos de otra base de datos. El propietario de un conjunto de tablas no debe ser capaz de entrar en las tablas de otro usuario. Los usuarios sólo deben ser capaces de acceder a los datos que se supone tienen acceso, e incluso entonces sólo deben ser capaces de realizar las acciones requeridas en los datos (por ejemplo, SELECT, pero no actualizar o borrar).

Todo esto se puede lograr dentro de SQL Server mediante un sistema integral, permisos jerárquicos donde los usuarios o roles (llamados principales) conceden o deniegan ciertos permisos específicos sobre determinados recursos (llamados elementos protegibles) como un objeto, esquema o base de datos. Una visión general de la jerarquía de permisos de SQL Server se ilustra en la imagen. 

Esto también implica que se siga principio del mínimo privilegio. Por ejemplo, no hacer que todos los desarrolladores accedan a la función db_owner de la base de datos. Restringir los permisos públicos y sólo conceder permisos en los niveles más bajos (usuario o rol) para minimizar el acceso directo. 

Para permitir que más permisos separados y una mejor separación de roles dentro de una base de datos, SQL Server introdujo la separación de esquemas de usuario, donde los esquemas son independientes de los usuarios de bases de datos y son sólo contenedores de objetos. Esto permite una mayor precisión para la gestión de permisos. Por ejemplo puede crearse un esquema que tienga permisos de control para desarrolladores de bases de datos. Se pueden hacer que les permita crear, modificar y eliminar todos los objetos dentro de los esquemas que controlan pero no tienen permisos implícitos a cualquier otro esquema dentro de la base de datos y ya no tienen derechos de db_owner para el desarrollo de bases de datos. Además, la separación de esquemas de usuario permite a los usuarios de bases de datos darles de baja sin tener que recodificar todos los objetos relacionados con el usuario dado de baja.  

Otra forma de evitar que los usuarios hagan cosas no permitidas es no permitir el acceso directo a sus tablas base. Esto puede hacerse proporcionando procedimientos y funciones que se utilizan para encapsular, controlar y aislar operaciones como las actualizaciones y eliminaciones almacenados, y proporcionando vistas que permiten controlar y seleccionar los datos óptimos.

Inyección SQL 

Uno de los métodos más comunes de obtener acceso no autorizado a los datos es utilizar un ataque de inyección SQL. La inyección de SQL puede tomar muchas formas, pero el enfoque principal es aprovechar  el código que utiliza cadenas construidas de forma dinámica e "inyectar" código inesperado en la query. Por ejemplo, el siguiente ataque de inyección se aprovecha de la lógica mal escrita para validar la entrada de usuario para engañar a SQL Server y obligarlo a aceptar la entrada al incluir caracteres de escape en la cadena de entrada. Aunque artificial, este ejemplo pone de relieve lo que puede suceder cuando el código se construye dinámicamente usando cadenas de entrada no es validadas a fondo:

DECLARE @ password VARCHAR (20);

DECLARE @input VARCHAR (20);

DECLARE @ExecStr VARCHAR (1000);

SELECT @ password = 'Mi_Password';

-- Asume que la aplicación obtiene de entrada 'OR' '='

SELECT @input = '' 'O' '' '=' '';

SELECT @ExecStr = 'SI' '' + @ password + '' 'LIKE' '' + @input + '' 'Imprimir' 'Contraseña Aceptada' '';

EXEC (@ExecStr);

GO

Si ejecuta este código, se imprimirá la frase "Contraseña aceptada" a pesar de que la entrada del usuario claramente no coincide con la cadena de contraseña. La entrada del usuario contenía una secuencia de escape que cambió la lógica de SQL porque la entrada no fue debidamente analizada y controlada. La inyección SQL no debería ser un problema para una aplicación bien escrita y hay algunos trucos específicos (como el uso de identificadores delimitados por comillas). Pero si se hereda una aplicación antigua, Se debe probar específicamente para ver si es vulnerable a ataques de inyección SQL. 

Recuperación de desastres

Los problemas de seguridad pueden ocurrir en muchos niveles. Existen algunas preocupaciones cuando la recuperación de desastres implica la conmutación a otro servidor SQL Server pero no se ha tenido la precaución de replicar los logins de sesión en el otro servidor por lo que los usuarios pierden el acceso, también hay un problema cuando surge la necesidad de restaurar una base de datos que contiene los datos cifrados.

En el primer caso, los problemas se producen cuando los inicios de sesión necesarios para acceder a la base de datos no se han duplicado en el servidor replicado por error, por ejemplo, cuando se utiliza el trasvase de registros. Si en la base de datos replicada la aplicación intenta conectarse a través de una entrada específica que no existe en el servidor replicado, la aplicación recibirá un error "acceso fallido". Los inicios de sesión son parte del sistema de aplicaciones y deben ser definidos en la instancia de la base de datos.

En el segundo caso, los problemas se producen cuando la copia de seguridad de base de datos contiene datos cifrados y la clave de cifrado (o teclas) que se utiliza para cifrar los datos no fueron replicados o no están disponibles en la instancia de SQL Server desde donde se está restaurando la base de datos. El mejor caso es si sólo una parte de los datos en la base de datos está encriptada por lo que sólo el subconjunto de datos encriptados no se podrá acceder. El peor escenario es que la totalidad de la base de datos esté cifrada. En ese caso, si el certificado de servidor utiliza para proteger la clave de cifrado de base de datos no fue replicado o no está disponible, la totalidad base de datos no puede ser restaurada y devolverá los siguientes errores:

No se puede encontrar el certificado del servidor con la huella digital

Uno de los objetivos de cifrar una base de datos es precisamente que no se podrá copiar y restaurar para evitar robos de datos, pero si se desea restaurar una base de datos cifrada,  entonces se debe disponer del certificado de servidor o si no,  se pierden los datos.

Revisión de cuentas

Una de las cosas más importantes que se debe hacer para mejorar la seguridad de un sistema es la implementación de una auditoría. Con esto, se sabrá quién está haciendo qué. 

Como mínimo, se deben auditar los intentos fallidos y exitosos de manera que se puede saber si, por ejemplo, cinco intentos de acceso fallidos fueron seguidos por un éxito.  De este modo es posible saber cuando alguien está tratando de entrar en la instancia de SQL Server (y con el que inicio de sesión). La figura muestra la configuración de auditoría de inicio de sesión a través del cuadro de diálogo Propiedades del servidor en SQL Server 2014.

Sobre El servidor en el explorador de objetos pulsamos el botón derecho del ratón y elegimos Propiedades 

Y elegimos la carpeta Seguridad.

Aquí hay más información sobre cómo auditar los inicios de sesión.