SQL Server Seguridad en Servidor

Introducción

Hablaremos de los aspectos de seguridad que se encuentran en el nivel de servidor de Microsoft SQL Server, en este punto debo precisar que solo hablare de los elementos que se pueden encontrar en la sección de Seguridad que se encuentra debajo de la sección de bases de datos, como se aprecia en la siguiente imagen:

Es posible apreciar qué se pueden encontrar 5 categorías, las cuales veremos en esta ocasión. Pero antes de iniciar con cada uno de los puntos, debe indicarse que la seguridad es uno de los principales aspectos que ha buscado mantener y mejorarse en Microsoft SQL Server. En Microsoft SQL Server la seguridad se puede apreciar como una serie de pasos que involucran cuatro grandes áreas: la plataforma, la autenticación, los objetos (incluyendo los datos) y las aplicaciones que acceden al sistema.

En el caso de la plataforma se incluye el hardware físico y los sistemas de red que permiten la conexión de los clientes con los servidores de la base de datos y los archivos binarios que son utilizados para procesar las solicitudes en la base de datos.

Para el caso de autenticación tenemos lo que en Microsoft SQL Server se identifican como principales, que son los individuos, grupos y procesos que tienen acceso al motor de bases de datos, a los individuos o grupos también se les conoce como inicios de sesión. Y por otro lado se encuentran los "asegurables" que se establecen como el servidor, la base de datos y los objetos que contiene la base de datos. Cada uno tiene un conjunto de permisos que se pueden configurar para ayudar a reducir el área de superficie de Microsoft SQL Server.

Microsoft SQL Server proporciona un conjunto de herramientas, utilidades, vistas y funciones que pueden usarse para configurar y administrar la seguridad. No hablaremos de todos los aspectos de seguridad, simplemente hablaremos de los aspectos de seguridad a nivel servidor que se encuentran en la sección correspondiente.

Logins (Inicios de sesión)

Los inicios de sesión constituyen los principios de seguridad en una instancia de Microsoft SQL Server. En este sentido, podemos encontrar los inicios de sesión autenticados por Windows de forma individual o de grupo. Esto significa que un inicio de sesión permite llevar a cabo la conexión a una instancia de Microsoft SQL Server.

Es importante indicar que los inicios de sesión que se mantienen en una instancia de Microsoft SQL Server dependerán del modo de autenticación que se haya definido en la misma, esto es, si se especifica autenticación de Windows, entonces se permitirá que los inicios de sesión sean autenticados por Windows, en caso de que el modo sea Microsoft SQL Server and Windows, entonces se permitirá la autenticación de los inicios de sesión a través de Microsoft SQL Server y de Windows respectivamente.

Para saber cuales son los inicios de sesión de una instancia podemos llevar a cabo la consulta de sys.server_principals, a continuación la consulta especifica para ver los inicios de sesión que se pueden encontrar en una instancia recién instalada.

-- Get the Logins from Principals

SELECT principal_id, name, type_desc, is_disabled, create_date

FROM sys.server_principals

WHERE type IN ('S','U')

Esta consulta nos presentara la lista de inicios de sesión conteniendo las cuentas de servicios de Microsoft SQL Server, las cuentas de administración de la instancia y algunos inicios de sesión autenticados por Microsoft SQL Server que generalmente se encuentran inhabilitados entre los que se encuentra el denominado administrador de sistema o sa.

Cuando se tiene el modo de autenticación de Microsoft SQL Server y Windows, los inicios de sesión se encontrarán en la anterior tabla, pero si desea saber cuales son los inicios de sesión que son únicamente de Microsoft SQL Server se debe llevar a cabo una consulta a sys.sql_logins, como se muestra a continuación:

-- Get the sql-logins

SELECT principal_id, name, type_desc, is_disabled, create_date, password_hash

FROM sys.sql_logins

En este caso, podemos observar qué se mantiene el valor de la contraseña asociado para el inicio de sesión, se mostrara encriptado en hash, ya que estos valores no deben ser fácilmente leíbles. En caso de que el modo de autenticación sea solo Windows, también se podrá llevar a cabo la consulta, pero solo mostrara los inicios de sesión iniciales inhabilitados.

Lo mas importante en este caso es mantener un adecuado registro de los inicios de sesión y los permisos que se otorgan a esos inicios de sesión, ya que es aquí donde se queda el registro de ellos. Para crear un inicio de sesión con autenticación de Windows se debe utilizar el siguiente comando:

USE [master]

GO

-- Create Login with Windows Authentication

CREATE LOGIN [LoginName] FROM WINDOWS WITH DEFAULT_DATABASE=[master]

GO

En el comando se puede observar que se esta indicando la sentencia FROM WINDOWS, de tal forma que, al ejecutarse, se le preguntará a Windows o Directorio Activo si el inicio de sesión que se está tratando de crear en la instancia de Microsoft SQL Server existe en el inventario de cuentas, en caso afirmativo, se incluirá en los inicios de sesión de la instancia y lo asignará a la base de datos master. Cabe mencionar que el inicio de sesión puede ser un grupo de cuentas de Windows, ello permitirá que todos los integrantes del grupo puedan tener acceso a la instancia de Microsoft SQL Server.

Para crear un inicio de sesión con autenticación de Microsoft SQL Server se utiliza el siguiente comando:

USE [master]

GO

-- Create Login with SQL Server Authentication

CREATE LOGIN [LoginName] WITH PASSWORD=N'Password' MUST_CHANGE, DEFAULT_DATABASE=[master], CHECK_EXPIRATION=ON, CHECK_POLICY=ON

GO

En el comando se observa que se establece la contraseña, la cual debe cambiarse después del primer uso, es importante notar que aquí el nombre del inicio de sesión se valida que no exista previamente en la instancia de Microsoft SQL Server, asimismo se indica que se asignara a la base de datos master.

En ambos casos se ha indicado la base de datos por omisión a master, este es un formulismo, ya que pudo haberse indicado alguna otra base de datos. En el caso de un inicio de sesión autenticado por Microsoft SQL Server, se sugiere que se establezca la validación de la expiración de la contraseña y las políticas para la creación de la contraseña, de tal manera que se tenga una contraseña fuerte adecuada a las políticas de contraseña de Windows de la computadora en la que se ejecuta Microsoft SQL Server deben aplicarse en este inicio de sesión. 

Debe recordarse que Microsoft recomienda como buena práctica que se utilicen únicamente inicios de sesión autenticados por Windows.

Server Roles

Los roles a nivel de servidor se proporcionan para ayudar en la administración los permisos en un servidor. Dichos roles también son principales de seguridad que permiten agrupar a otros principales. De esta manera, los roles de nivel de servidor abarcan todo el servidor en lo referente al alcance de los permisos. (Los roles pueden ser comparados como los grupos que se manejan en el sistema operativo Windows). Hasta la versión 2012, los roles de servidor ya se encontraban definidos y no podían definirse roles adicionales o definidos por la administración de bases de datos, es por ello por lo que se proporcionan roles de servidor fijos para mayor comodidad y compatibilidad con las versiones anteriores. es una buena idea conocer mas sobre los roles de nivel servidor.

Para obtener los roles de nivel servidor que se encuentran definidos actualmente en la instancia podemos ejecutar el siguiente procedimiento almacenado:

-- Get the server-level roles

sp_helpsrvrole

con ello podemos obtener la siguiente lista:

ServerRole	Description
sysadmin	System Administrators
securityadmin	Security Administrators
serveradmin	Server Administrators
setupadmin	Setup Administrators
processadmin	Process Administrators
diskadmin	Disk Administrators
dbcreator	Database Creators
bulkadmin	Bulk Insert Administrators

En este caso, podemos definir brevemente cada uno de los roles que se encuentran definidos por omisión en la instancia, para poder aplicarlos adecuadamente.

Rol sysadmin

El rol sysadmin, como su nombre lo indica, permite que el miembro que pertenece a este rol puede hacer cualquier cosa dentro de Microsoft SQL Server, esto es, tiene derechos completos sobre la instancia de Microsoft SQL Server. Es el único rol que puede agregar otros miembros al rol sysadmin.

Un punto importante sobre el rol del administrador del sistema es que evita las verificaciones de seguridad. Denegar permisos no detiene una función de administrador de sistemas, ya que un miembro de esta función anula por completo cualquier configuración de seguridad. El rol sysadmin es realmente un tipo de rol de super-usuario. Es eso por lo que debe tenerse mucho cuidado en otorgar este rol. Se ha indicado que es una buena practica que existan pocos miembros dentro de este tipo de rol, para un mejor control de los recursos.

Rol securityadmin

El rol securityadmin se utiliza para la administración de cuentas de usuario dentro de Microsoft SQL Server. En forma similar al grupo Account Manager en Windows, la función de securityadmin tiene capacidad para la creación (agregar) y eliminar inicios de sesión dentro la instancia de Microsoft SQL Server.

El rol de securityadmin tiene todos los derechos necesarios para habilitar que los usuarios se conecten a la instancia de Microsoft SQL Server. Sin embargo, los permisos que tiene securityadmin terminan allí. El rol securityadmin es a nivel de servidor, pero no tiene derechos para asignar permisos de acceso a una base de datos.

Rol serveradmin

El rol serveradmin tiene la capacidad de establecer opciones de configuración usando el procedimiento almacenado sp_configure, así como de apagar el servicio de Microsoft SQL Server. No hay mucho que decir sobre esto porque me imagino que este rol no se usa con mucha frecuencia. Si un usuario necesita la capacidad de cerrar Microsoft SQL Server y poco más, ese usuario generalmente lo hace a través del servicio (como un miembro del equipo del servidor).

Rol setupadmin

El rol setupadmin es bastante limitado. Tiene la capacidad de administrar servidores vinculados, así como marcar procedimientos almacenados para ejecutarse en el inicio de servicios. El procedimiento almacenado del sistema sp_procoption se puede utilizar para marcar un procedimiento almacenado de esa forma.  Los procedimientos marcados deben existir en la base de datos master, pertenecer a dbo y no pueden contener parámetros de entrada o salida.

Rol processadmin

El rol processadmin es otro rol con una funcionalidad bastante limitada pero potente. Un usuario asignado a este rol tiene la capacidad de ejecutar el comando KILL, pero no otros derechos. Sin embargo, con el comando KILL, el usuario con el rol processadmin tiene un poder enorme ya que puede detener una consulta que se ejecuta en Microsoft SQL Server.

Rol diskadmin

La función fija de servidor diskadmin básicamente tiene la capacidad de agregar y eliminar dispositivos de respaldo.

Rol dbcreator

El rol dbcreator tiene la capacidad de crear, eliminar y restaurar bases de datos. Cuando se crea una base de datos, el creador asume automáticamente la propiedad de esa base de datos. Por lo tanto, un inicio de sesión con el rol dbcreator puede inicialmente asignar permisos, crear objetos y todas las demás cosas que un usuario del rol db_owner puede hacer en las bases de datos que ha creado (al menos, hasta que se cambie la propiedad).

Típicamente, aquellos inicios de sesión con permisos de rol sysadmin manejan la creación y administración de bases de datos. Estos permisos les otorgan automáticamente estas habilidades. Hay que usar el rol de servidor dbcreator con moderación. Hay que recordar que dbcreator puede eliminar una base de datos tan fácilmente como crear una nueva, aunque sí hay una buena copia de seguridad, el usuario también tiene la capacidad de restaurarla.

Rol bulkadmin

El rol bulkadmin permite que los usuarios no administrativos puedan usar el comando BULK INSERT. Anteriormente, solo los miembros del rol sysadmin podían ejecutar BULK INSERT. Si se agrega un inicio de sesión al rol de servidor bulkadmin, ese inicio de sesión tiene la capacidad de usar BULK INSERT. Este rol adicional proporciona una gran flexibilidad ya que ahora hay una opción diferente al rol sysadmin. Esto hace posible delegar el uso de BULK INSERT a otros inicios de sesión. Los usuarios aún tienen que ser el propietario del objeto o la base de datos, por lo que este rol no otorga una carta blanca en todas las tablas en todas las bases de datos.

Para asignar a un inicio de sesión el rol determinado, se puede ejecutar el siguiente comando:

-- Set server role to login

ALTER SERVER ROLE [] ADD MEMBER [];

Para saber que roles de nivel servidor tienen los inicios de sesión actualmente, podemos utilizar la siguiente consulta:

--- This query help to identify the logins and the roles granted on server

WITH sys_ServerRoles

AS

(

       SELECT principal_id, name as ServerRole

         FROM msdb.sys.server_principals sp

        WHERE type = 'R'

)

SELECT sp.name as UserName, sr.ServerRole, sp.create_date

  FROM msdb.sys.server_role_members srm

       INNER JOIN sys.server_principals sp ON srm.member_principal_id = sp.principal_id

       INNER JOIN sys_ServerRoles sr ON srm.role_principal_id = sr.principal_id

 ORDER BY UserName;

Como se sabe, a partir de la versión 2012 ya es posible crear nuevos roles a nivel servidor, hay que recordar que los roles de servidor son asegurables a nivel de servidor. Después de crear una función de servidor, se hace necesario configurar los permisos de nivel de servidor de la función mediante GRANT, DENY y REVOKE. Por lo que para crear un nuevo rol a nivel de servidor se hace preciso ejecutar el siguiente comando:

USE [master]

GO

-- Create a Server Role

CREATE SERVER ROLE []

GO

Se sugiere conocer más sobre el comando Create Server Role.

Credenciales

Microsoft SQL Server permite a los usuarios agregar credenciales a una base de datos. Las credenciales, generalmente son nombres de usuario y contraseñas de Windows, se pueden usar para acceder a recursos fuera de Microsoft SQL Server. Múltiples inicios de sesión SQL pueden usar una credencial para acceso externo. Un ejemplo simple de uso de credenciales es la cuenta proxy de Microsoft SQL Server.

Una credencial es un registro que contiene la información de autenticación (credenciales) requerida para conectarse a un recurso fuera de Microsoft SQL Server. Esta información es utilizada internamente por Microsoft SQL Server. La mayoría de las credenciales contienen un nombre de usuario y contraseña de Windows.

La información almacenada en una credencial permite a un usuario que se ha conectado a Microsoft SQL Server a través de la autenticación de Microsoft SQL Server acceder a recursos fuera de la instancia del servidor. Cuando el recurso externo es Windows, el usuario se autentica como el usuario de Windows especificado en la credencial. Una sola credencial solo se puede asignar a un único inicio de sesión de Microsoft SQL Server. Y un inicio de sesión de Microsoft SQL Server se puede asignar a una sola credencial.

Para obtener la información de las credenciales que se encuentran definidas, podemos usar la siguiente consulta:

-- Get the Security Credentials

SELECT credential_id, name, credential_identity, create_date

FROM sys.credentials

Para crear una credencial en la instancia de Microsoft SQL Server se debe ejecutar el siguiente comando:

USE [master]

GO

--- Create a New Credential

CREATE CREDENTIAL [CredentialName] WITH IDENTITY = N'', SECRET = N''

GO

Proveedores criptográficos

El proveedor criptográfico es el componente de software que realmente genera el par de claves que proporciona capacidades de cifrado de datos junto con la administración de claves extensibles (Extensible Key Management o EKM). Los proveedores de hardware proporcionan productos que abordan la gestión de claves empresariales mediante el uso de módulos de seguridad de hardware (Hardware Security Modules o HSM). Los dispositivos HSM almacenan claves de cifrado en módulos de hardware o software. Microsoft SQL Server generalmente admite las API estándar de Windows e identifica que algoritmos, fortalezas clave, etc. de infraestructura de clave pública (Public Key Infrastructure o PKI). Las claves de cifrado para los datos y claves se crean en contenedores de claves transitorias, y éstas deben exportarse desde un proveedor antes de almacenarse en la base de datos. Este enfoque permite la administración de claves que incluye una jerarquía de claves de cifrado y una copia de seguridad de claves, que pueda ser manejada por Microsoft SQL Server.

La administración de claves extensible en Microsoft SQL Server permite a los proveedores de EKM / HSM de terceros registrar sus módulos en Microsoft SQL Server. Cuando están registrados, los usuarios en una sesión de Microsoft SQL Server pueden usar las claves de cifrado almacenadas en los módulos EKM. Esto permitirá que Microsoft SQL Server pueda acceder a las funciones de cifrado avanzadas que admiten estos módulos, como el cifrado y descifrado en masa, y las funciones de administración de claves, como el vencimiento y la rotación de las claves.

Es importante indicar que esta funcionalidad solo esta disponible en la edición Empresarial (Enterprise) de Microsoft SQL Server, es por esta razón que la administración de claves extensible se encuentra desactivada por omisión. Para habilitar esta funcionalidad, debe usarse el comando sp_configure que tiene la opción correspondiente, use es siguiente comando para habilitarlo:

-- Enable show advanced options

sp_configure 'show advanced', 1 

GO 

RECONFIGURE 

GO

-- Enable EKM Provider

sp_configure 'EKM provider enabled', 1 

GO 

RECONFIGURE WITH OVERRIDE

GO

Aquí debe mencionarse que todas las claves creadas por un proveedor harán referencia al proveedor por su GUID, mismo que se retiene en todas las versiones de la DLL. Esta DLL que implementa la interfaz SQLEKM debe firmarse digitalmente con cualquier certificado. Así que Microsoft SQL Server verificará la firma digital. Esto incluye su cadena de certificados, que debe tener su raíz instalada en la ubicación de las Autoridades de certificación raíz de confianza en un sistema Windows.

Para obtener una lista de los proveedores criptográficos en la instancia de Microsoft SQL Server, utilice la siguiente consulta

-- Get the Security Cryptographic Providers

SELECT provider_id, name, guid, version, dll_path, is_enabled

FROM sys.cryptographic_providers

Para crear un proveedor criptográfico en una instancia de Microsoft SQL Server, como ya se indicó, debe ser una edición Empresarial, usaremos el siguiente comando:

USE [master]

GO

-- Create a Cryptographic provider

CREATE CRYPTOGRAPHIC PROVIDER [provider_name] FROM FILE = [path_of_DLL] 

GO

Este es un tema que debe ser analizado de forma más extensa, de tal forma que podemos conocer más acerca de la administración de claves extensibles y del uso del comando create cryptographic provider

Auditorias

La auditoría en una instancia de Microsoft SQL Server en el motor de bases de datos o de una base de datos individual implica llevar a cabo el seguimiento y registro de todos los eventos que ocurren dentro del Motor de base de datos. La auditoría en Microsoft SQL Server permite crear auditorías a nivel de servidor, que pueden contener especificaciones para eventos de nivel de servidor y especificaciones relacionadas con la auditoria de base de datos para eventos en ese nivel. Los eventos auditados pueden escribirse en los registros de eventos del equipo o en archivos de auditoría específicos.

Como se ha indicado, existen varios niveles de auditoría para Microsoft SQL Server, dependiendo de los requisitos gubernamentales o estándares para su instalación. Microsoft SQL Server Audit proporciona las herramientas y procesos para habilitar, almacenar y ver auditorías en varios servidores y objetos de bases de datos.

Es importante indicar que todas las ediciones de Microsoft SQL Server admiten auditorías a nivel de servidor. Sin embargo, esto es válido a partir de Microsoft SQL Server 2016 (13.x) SP1, ya que anteriormente, la auditoría a nivel de base de datos se limitaba a las ediciones Enterprise, Developer y Evaluation.

El SQL Server Audit recopila una única instancia de servidor o acciones a nivel de base de datos y los grupos de acciones para supervisar. Se debe notar que la auditoría está en el nivel de instancia de Microsoft SQL Server y es posible tener múltiples auditorías por instancia de Microsoft SQL Server. Cuando se define una auditoría, debe especificarse la ubicación para la salida de los resultados; esto es, debe indicarse el destino de la auditoría. Cuando se define una auditoría se crea en un estado inhabilitado y no se lleva a cabo auditoria automáticamente de alguna acción. Después de habilitar la auditoría, el destino de la auditoría recibe datos auditados.

Para obtener una lista de las auditoria de servidor, podemos ejecutar la siguiente consulta:

-- Get the Security Server Audits

SELECT audit_id, name, audit_guid, create_date, principal_id, type_desc, on_failure_desc, is_state_enabled

FROM sys.server_audits

GO

Para crear una auditoria de servidor, se ejecuta el siguiente comando:

USE [master]

GO

-- Create a server audit to a specific file

CREATE SERVER AUDIT [AuditName] TO FILE (FILEPATH ='AuditFilePath'); 

GO

USE [master]

GO

-- Create a server audit to windows application log

CREATE SERVER AUDIT [AuditName] TO APPLICATION_LOG WITH (QUEUE_DELAY = 1000, ON_FAILURE = CONTINUE);

GO

Como se ha indicado, cuando se crea una auditoria en la instancia, ésta se crea en un estado inhabilitado, para habilitar una auditoria, utilizamos el siguiente comando:

-- Enable the server audit. 

ALTER SERVER AUDIT [AuditName]  

WITH (STATE = ON) ;

GO

Aquí solo hemos visto las características generales de la auditoria y la creación de una auditoria a nivel de la instancia dentro del motor de base de datos de Microsoft SQL Server, se sugiere revisar la información referente a Auditoria de Microsoft SQL Server y del comando CREATE SERVER AUDIT.

Especificaciones de auditoria de servidor

El objeto de Especificación de auditoría del servidor pertenece a una auditoría. Puede crear una especificación de auditoría de servidor por auditoría, porque ambas se crean en el ámbito de la instancia de Microsoft SQL Server. La especificación de auditoría del servidor recopila muchos grupos de acción a nivel de servidor generados por la función Eventos extendidos. Puede incluir grupos de acciones de auditoría en una especificación de auditoría del servidor. Los grupos de acciones de auditoría son grupos de acciones predefinidos, que son eventos atómicos que ocurren en el Motor de base de datos. Estas acciones se envían a la auditoría, que las registra en el objetivo. Para obtener una lista de los grupos de acciones de auditoría, por favor revise la página correspondiente a Grupos y acciones de acciones de auditoría de Microsoft SQL Server.

Para obtener una lista de las especificaciones de auditoria definidas es la instancia, se puede llevar a cabo la siguiente consulta:

-- Get the Security Server Audit Specifications

SELECT server_specification_id, name, create_date, audit_guid, is_state_enabled

FROM sys.server_audit_specifications

GO

Para crear un objeto de especificación de auditoría del servidor utilizando la función Auditoría de Microsoft SQL Server, el nombre de un grupo de acciones auditables a nivel de servidor debe ser indicado cuando se crea la especificación de auditoria de servidor, se utiliza el comando:

-- Create a Server Audit specification

CREATE SERVER AUDIT SPECIFICATION [AuditNameSpecification]

FOR SERVER AUDIT [AuditName] 

    ADD ([audit_action_group_name]); 

GO

Se debe tener en cuenta que previamente debe existir una auditoría de servidor antes de crear una especificación de auditoría del servidor. Cuando se crea una especificación de auditoría del servidor, al igual que pasa con la creación de auditoria de servidor, se crea con un en estado inhabilitado. Es por lo que después de crear una especificación debemos ejecutar el comando:

-- Enable a Server Audit specification

ALTER SERVER AUDIT SPECIFICATION [AuditNameSpecification]  

FOR SERVER AUDIT [AuditName]  

WITH (STATE=ON);

Conclusión

Aquí hemos visto de forma muy general lo referente a la seguridad de los objetos de servidor, que se encuentran en la sección correspondiente, se sugiere el estudio a fondo de cada una de las áreas de seguridad que indica Microsoft SQL Server. Este documento trata de dar una vista general de los tópicos indicados, mostrando algunos comandos para obtener información o cómo crear los objetos asociados, pretende servir como guía para ayudar a la comprensión de los elementos indicados.