Opciones de configuración de seguridad
Introducción
Microsoft
SQL Server, desde hace algún tiempo, ha proporcionado una arquitectura de
seguridad diseñada para permitir que los administradores y desarrolladores de
bases de datos puedan crear aplicaciones de bases de datos que sean seguras y ayuden
a contrarrestar amenazas. Cada instancia de Microsoft SQL Server contiene una colección
jerárquica de entidades, iniciando con el servidor.
De esta
forma el acceso a cada instancia del servidor es la primera entidad que debe
ser segura, para que las múltiples bases de datos que contiene sean seguras. Para Microsoft SQL Server se define un principal como la entidad que puede solicitar recursos
dentro de una instancia. Dentro del marco de seguridad que maneja Microsoft SQL Server,
se gestiona el acceso a través de la autenticación y la autorización a los
objetos.
· La
autenticación en Microsoft SQL Server es el proceso de iniciar sesión mediante el cual un
principal solicita acceso mediante el envío de credenciales que el servidor
evalúa. La autenticación establece la identidad del usuario o proceso que se
está autenticando.
· La
autorización es el proceso de determinar a qué recursos asegurables puede
acceder un principal y qué operaciones están permitidas para esos recursos.
De esta
forma, cuando se configura la seguridad de la instancia, se deben indicar el
modo de autenticación que se tendrá, y las características de registro de auditoria que se debe llevar a
cabo en la instancia. Ya se ha visto en las Opciones de Configuración que para
las características de auditoria y de encadenamiento de propiedad entre bases
de datos se pueden establecer con las siguientes opciones:
Nombre de opción
|
Descripción
|
c2 audit mode
|
modo de auditoría c2
|
common criteria compliance
enabled
|
Modo de cumplimiento Common Criteria habilitado
|
cross db ownership chaining
|
Permitir el encadenamiento
de propiedad cross db
|
No
obstante, aunque el modo de autenticación a la instancia es definido desde la
instalación, es posible modificarlo, como veremos en esta ocasión, además de
indicar el modo de auditoria que se lleva en al registro de Microsoft SQL Server.
Ya hemos
indicado que algunas opciones de configuración en Microsoft SQL Server pueden
identificarse como avanzadas, por lo que en caso de utilizar el procedimiento
almacenado de sistema sp_configure,
se debe habilitar la posibilidad de despliegue de dichas opciones avanzadas.Opción Autenticación en servidor
Para esta
opción de configuración, que no se encuentra en el listado de opciones
previamente indicadas, Microsoft SQL Server permite dos modos de autenticación, el modo
de autenticación de Windows y modo mixto, entendiendo con ello, la
autenticación de Windows y autenticación de Microsoft SQL Server de modo indistinto.
El modo de autenticación
de Windows es el modo predeterminado, también se denomina seguridad integrada indicando
que el modelo de seguridad de Microsoft SQL Server está estrechamente integrado con
Windows. De esta forma, Microsoft SQL Server confía en las cuentas específicas de
usuarios y grupos de Windows para iniciar sesión y permitir el acceso al
usuario portador de estas credenciales, siempre que el usuario haya sido
autorizado previamente. Los usuarios de Windows que ya han sido autenticados no
tienen que presentar credenciales adicionales.
El modo de
autenticación mixto, como se ha indicado permite la autenticación tanto de los
usuarios de Windows como de los usuarios definidos únicamente en Microsoft SQL Server,
donde los pares de nombre de usuario y contraseña se mantienen.
Es importante
indicar que si cuando se instala la instancia de Microsoft SQL Server, se indica que se
permitirá el modo de autenticación Windows, entonces solo los usuarios que están
registrados en Windows podrán acceder, sin embargo, en ocasiones es necesario
generar inicios de sesión de acceso en Microsoft SQL Server y en muchas instalaciones se indica
el modo de autenticación mixto.
Al usar
autenticación de modo mixto, si se han creado inicios de sesión de Microsoft SQL Server, se
debe proporcionar el nombre de usuario y la contraseña de la instancia de Microsoft SQL Server
en tiempo de ejecución, o bien utilizar las credenciales de Windows para
acceder a la instancia de Microsoft SQL Server.
La opción
de configuración del modo de autenticación de la instancia de Microsoft SQL Server se
mantiene en el registro de Windows, donde se mantiene el valor dentro de la
llave LoginMode, en éste se pueden encontrar dos valores:
·
1
= Modo de Autenticación Windows
·
2
= Modo de Autenticación Mixto (Windows and Microsoft SQL Server)
En este
ejemplo se cambiará el modo de autenticación mixto en la instancia de default
USE [master]
GO
-------------------------------------------------------------------------
-- Cambiar el modo de
Autenticación
--------------------------------------------------------------------------
--
EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE',
N'Software\Microsoft\MSSQLServer\MSSQLServer',
N'LoginMode',
REG_DWORD,
2
GO
NOTA:
Microsoft siempre ha recomendado utilizar la autenticación de Windows
siempre que sea posible. La autenticación de Windows usa una serie de mensajes
cifrados para autenticar usuarios en Microsoft SQL Server. Cuando se utilizan los inicios
de sesión de Microsoft SQL Server, los nombres de inicio de sesión y las contraseñas de Microsoft SQL Server se pasan a través de la red, lo que los hace menos seguros.
Opción Nivel de Auditoria
La opción
de configuración de nivel de auditoría expone el comportamiento de registro de
autenticación de Microsoft SQL Server. El registro de autenticación escribe las entradas
de registro dentro del registro de errores de Microsoft SQL Server y en el
registro de aplicación de Windows.
La opción
de configuración del nivel de auditoría de la instancia de Microsoft SQL Server se
mantiene en el registro de Windows, donde se mantiene el valor dentro de la
llave AuditLevel, en éste se tienen las siguientes opciones:
·
0
= No registra intentos de autenticación.
·
1
= Registros de autenticación exitosa.
·
2
= Registros de autenticación fallida.
·
3
= Registra todos los intentos de autenticación independientemente del éxito o
el fracaso.
En este ejemplo
se cambiara el nivel de auditoria a solo los registros de autenticación exitoso.
USE [master]
GO
--
--- Change Audit Level
--
EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE',
N'Software\Microsoft\MSSQLServer\MSSQLServer',
N'AuditLevel',
REG_DWORD,
1
GO
NOTA:
Esta característica se eliminará en una versión futura de Microsoft SQL
Server. Evite usar esta característica en nuevos trabajos de desarrollo y
planee modificar las aplicaciones que actualmente usan esta característica.
Opción Cuenta de proxy al servidor
Idealmente una
aplicación que se conecta a Microsoft SQL Server necesita acceder a objetos y recursos
dentro de la instancia únicamente. Sin embargo, es frecuente que la aplicación
necesité acceder a recursos externos del sistema, como archivos, la red,
variables de entorno. Es posible que la aplicación necesite ejecutar el
procedimiento almacenado extendido xp_cmdshell para invocar un shell de
comandos de Windows y ejecutar un comando de shell para recuperar una lista de
archivos en un directorio.
Cuando un
miembro de la función sysadmin de la instancia ejecuta el procedimiento
almacenado extendido xp_cmdshell, el proceso de Windows del shell de comandos
se ejecuta con el contexto de seguridad de la cuenta de servicio de Microsoft SQL Server.
En un ambiente seguro, la cuenta de
servicio de Microsoft SQL Server es una cuenta que no tiene permisos administrativos
sobre el servidor, de tal forma que si se requiere acceder a elementos que
requieran las habilidades administrativas, es por ello que la cuenta proxy nos
apoya en lograr ese objetivo.
En Microsoft SQL
Server para permitir que un inicio de sesión que no sea sysadmin pueda ejecutar el procedimiento almacenado extendido xp_cmdshell,
entonces el administrador debe crear una credencial de sistema especial denominado”##
xp_cmdshell_proxy_account ##” y especificar una cuenta de Windows. Esta
cuenta se usará para ejecutar xp_cmdshell
por usuarios que no son miembros de la función sysadmin.
En este
ejemplo se genera la cuenta de proxy asociada a la cuenta Windows WinAccount.
USE [master]
GO
--
-- Change to create a proxy shell account
--
CREATE CREDENTIAL [##xp_cmdshell_proxy_account##]
WITH IDENTITY = N'WinAccount', SECRET = N'Pa$$5w0rd'
GO
Es
importante indicar que para que un inicio de sesión pueda ejecutar el
procedimiento almacenado extendido xp_cmdshell
requiere que se habilite la opción de configuración xp_cmdshell.
Opción c2 audit mode
Desde hace
tiempo, el Departamento de Defensa de EE. UU. ha establecido un conjunto de
calificaciones que se aplican a los niveles de seguridad de los sistemas
informáticos, en función de sus capacidades con respecto a la auditoría y el
control de acceso discrecional. De acuerdo con esta clasificación, Microsoft
SQL Server tiene la opción de configuración del modo de auditoría C2. Todas las
versiones de Microsoft SQL Server tienen certificación C2 (siempre que se ejecute en una
computadora y red certificadas por C2). En consecuencia, Microsoft SQL Server garantiza
que sus procedimientos de auditoría satisfacen los requisitos de C2, por
ejemplo, el almacenamiento de datos generados solo en una partición NTFS.
La
información de los registros de auditoría C2 van más allá de los eventos a
nivel de servidor, como apagar o reiniciar, los intentos de inicio de sesión
fallidos y exitosos, ampliar el uso exitoso y fallido de permisos al acceder a
objetos de bases de datos individuales y ejecutar toda la definición de datos, el
control de acceso a datos y la manipulación de datos a través de las declaraciones
de lenguaje.
La
información del registro de auditoría contiene la marca de tiempo de
realización del evento, el identificador de la cuenta que desencadenó el
evento, el nombre del servidor de destino, el tipo de evento, su resultado
(éxito o fracaso), el nombre de la aplicación del usuario e ID de proceso del
servidor de la conexión del usuario y el nombre de la base de datos. Seleccionar
esta opción de configuración permitirá que la instancia de Microsoft SQL Server registre
los intentos fallidos y exitosos para acceder a las declaraciones y objetos.
Esta información nos ayuda a perfilar la actividad del sistema y rastrear
posibles violaciones de las políticas de seguridad establecidas.
Los datos
del registro de modo de auditoría C2 se almacenan en un archivo en el directorio
predeterminado de datos de la instancia, dicho archivo de registro de auditoría
puede alcanzar hasta 200 megabytes (MB) en tamaño, una vez que se ha alcanzado
el límite indicado se creará un nuevo archivo, cerrando el archivo anterior y
escribirá todos los registros de auditoría nuevos en el nuevo archivo. El proceso
de escritura en el registro continuará hasta que el directorio de datos, donde
se lleva a cabo el registro de auditoría se llene o se deshabilite la auditoría.
Importante:
El modo de auditoría C2 guarda una gran cantidad de información de los eventos
en el archivo de registro, por lo que puede crecer rápidamente. Si el
directorio de datos en el que se guardan los registros se queda sin espacio,
provocará que Microsoft SQL Server se cierre
automáticamente. En el caso de que la auditoría está configurada para un inicio
automático, se debe reiniciar la instancia con la bandera -f (que permite omitir la auditoría) o bien
liberar espacio adicional en el disco para mantener el registro de auditoría.
En este ejemplo
se habilitara la opción de configuración de modo de auditoria c2
EXEC sys.sp_configure N'c2 audit mode', N'1'
RECONFIGURE WITH OVERRIDE
GO
La opción
de configuración de modo de auditoria C2 es una opción avanzada. Si se utiliza el
procedimiento almacenado del sistema sp_configure
para establecer la configuración, recuerde habilitar que se muestren las opciones
avanzadas. Después de ejecutar el comando RECONFIGURE el valor solicitado se
aplica inmediatamente sin necesidad de reiniciar los servicios de Microsoft SQL Server.
Nota:
Microsoft ha indicado que ésta característica se eliminará en una
versión futura de Microsoft SQL Server, por lo que recomienda evitar su uso. El estándar
de seguridad C2 ha sido reemplazado por Common Criteria Certification.
Opción common criteria compliance enabled
El Common
Criteria Compliance (generalmente se abrevia como CC) es un método para
asegurar que los productos de las tecnologías de información cumplen con un
conjunto definido de especificaciones de seguridad. Lo que se intenta es estandarizar
la evaluación de seguridad para una amplia variedad de sistemas. En general, Common
Criteria se define como un marco en el que los usuarios de sistemas
informáticos pueden especificar sus requisitos de seguridad funcional y de aseguramiento
mediante el uso de perfiles de protección, de esta manera Common Criteria
proporciona la seguridad de que el proceso de especificación, implementación y
evaluación de un producto de seguridad informática se ha llevado a cabo de
manera rigurosa, estándar y repetible a un nivel acorde con el entorno objetivo
para su uso.
Common
Criteria se utiliza como base para un esquema de certificación impulsado por el
gobierno y, por lo general, las evaluaciones se llevan a cabo para el uso de
las agencias del gobierno federal y la infraestructura crítica. Es
"intencionalmente flexible", lo que significa que inicialmente se
otorga cierta libertad a la implementación de los requisitos necesarios
definidos en el acuerdo de nivel de evaluación (Evaluation Agreement Level ‘EAL’).
Por tal motivo le corresponde al vendedor determinar una adecuada implantación,
según el nivel de garantía de evaluación que se haya previsto. Una aplicación
específica se conoce como Objetivo de evaluación. Los términos tienen un rango
considerablemente amplio sobre lo que pueden hacer referencia. En este caso,
nuestro objetivo de evaluación es una instalación de Microsoft SQL Server. Profundizar en
este tema va más allá del alcance de este documento, para profundizar visite la documentación correspondiente de Microsoft SQL Server.
No obstante,
lo anterior, antes de habilitar la opción de configuración de common criteria
compliance enabled, debe indicarse que solo se evalúan y certifican para las
ediciones Enterprise y Datacenter. Asimismo, es importante indicar no todos los
paquetes de servicio están soportados
para cumplir con los requisitos, por lo que es necesario validar la versión,
edición y nivel de Microsoft SQL Server con que se cuenta, para llevar a cabo la
habilitación de esta opción.
En este
ejemplo se habilitara la opción de configuración common criteria compliance
enabled
EXEC sys.sp_configure N'common criteria compliance enabled', N'1'
RECONFIGURE WITH OVERRIDE
GO
Importante
Además de habilitar la opción, también debe descargarse y ejecutarse un
script que finaliza la configuración de SQL Server para cumplir con Common
Criteria Evaluation Assurance Level. Para ello, viste la documentación de Microsoft SQL Server.
La opción
de configuración common criteria compliance enabled es una opción avanzada. Si se
utiliza el procedimiento almacenado del sistema sp_configure para establecer la configuración, recuerde habilitar
que se muestren las opciones avanzadas. Después de ejecutar el comando
RECONFIGURE el valor solicitado se aplica inmediatamente sin necesidad de
reiniciar los servicios de Microsoft SQL Server.
Opción cross db ownership chaining
En Microsoft SQL
Server todos los objetos, como tablas y vistas, tienen un propietario, el que puede
proceder indirectamente del propietario del esquema al que pertenece el objeto.
Para efectos de esta opción de configuración indicar que el encadenamiento de
propiedad cruzada de la base de datos es una extensión del encadenamiento de
propiedad, excepto que cruza el límite de la base de datos. Un ejemplo en el
que se puede producir un encadenamiento de propiedad cruzada de bases de datos es
si tiene una vista en una base de datos que hace referencia a una tabla en otra
base de datos. La vista en la primera base de datos se refiere a una tabla en
la segunda base de datos. Si estuviéramos hablando de objetos dentro de la
misma base de datos, si tanto la tabla como la vista eran propiedad del mismo
usuario, se formaría una cadena de propiedad donde el usuario final solo
necesitaría acceder a la vista. Con el encadenamiento de propiedad cruzada de
la base de datos, eso mismo es posible, excepto en las bases de datos.
El
encadenamiento de propiedad cruzada de la base de datos se puede activar a
nivel servidor o a nivel de base de datos. Si el encadenamiento de propiedad cruzada
de la base de datos está activado a nivel servidor, está activado para todas las
bases de datos en ese servidor, independientemente de las configuraciones
individuales de cada una de las bases de datos. No es recomendable establecer la
opción de configuración cross db ownership chaining en 1, a menos que todas las
bases de datos que se encuentren en la instancia de Microsoft SQL Server participen en el
encadenamiento de propiedad entre bases de datos y se conocen las implicaciones
de seguridad de esta configuración.
Si para
alguna aplicación se ha utilizado el encadenamiento de propiedad, antes de desactivar
el encadenamiento de propiedad entre bases de datos en un servidor de
producción, deberá probar todas las aplicaciones que se tienen, para garantizar
que los cambios no afecten a la funcionalidad de la aplicación en cuestión.
En este
ejemplo se habilitará la opción de configuración cross db ownership chaining
EXEC sys.sp_configure N'cross db ownership chaining', N'1'
RECONFIGURE WITH OVERRIDE
GO
La opción
de configuración cross db ownership chaining es una opción avanzada. Si se
utiliza el procedimiento almacenado del sistema sp_configure para establecer la configuración, recuerde habilitar
que se muestren las opciones avanzadas. Después de ejecutar el comando
RECONFIGURE el valor solicitado se aplica inmediatamente sin necesidad de
reiniciar los servicios de Microsoft SQL Server.
Comentarios
Como se ha
observado, conocer las opciones de configuración de seguridad es una de las principales
responsabilidades de un Microsoft SQL Server Database Administrator, es importante
conocer las características relativas en cuanto a las implicaciones de
modificar los valores, particularmente las relativas al cumplimiento de los
niveles de auditoria requeridos, los efectos de habilitar un proxy para
ejecución de scripts en el Shell de Windows y los modos de autenticación
requeridos.
En este
punto podemos decir que se han visto cada una de las opciones de configuración relativas
a seguridad de nivel instancia de servidor, estas mismas opciones aparecen en
la pestaña de seguridad de la ventana de propiedades del servidor, como se
puede observar en la siguiente imagen:
Como se ha
mencionado anteriormente, es posible realizar el cambio de alguna de las
opciones de configuración en esta ventana, ya que los valores se muestran y
están habilitados, es preferible llevar a cabo la modificación de estos valores
con el procedimiento almacenado de sistema denominado sp_configure, para el caso de las opciones de habilitación, o
ejecutar los comandos correspondientes, para las otras opciones, de esta forma
se puede mantener un control apropiado sobre los valores indicados en la opción
de configuración.
No hay comentarios.:
Publicar un comentario