Base de Datos II SQL Server 2014 - Seguridad Clase 8

Clase Seguridad

Seguridad

+ - Seleccionar
un Modo de Autenticación
o Inicios de Sesión
- Usuarios

* Esquemas
de Base de Datos

1]
Base de Datos II SQL Server 2014 - Seguridad Clase 8

Introducción

La Arquitectura de seguridad es uno de los aspectos que más cambios ha sufrido y en

el que más mejoras se han introducido en SQL Server 2005. En el presente apartado
veremos los aspectos básicos de seguridad que será necesario tener en cuenta a la
hora de acceder a una base de datos SQL Server Express.
SQL Server admite los siguientes tipos de inicios de sesión:
+ — Una cuenta de usuario local de Windows o una cuenta de dominio de Active Directory:
SQL Server usa Windows para autenticar cuentas de usuario de Windows.
+ Grupo de Windows: conceder acceso a un grupo de Windows otorga acceso a todos los
inicios de sesión de usuario de Windows que son miembros del grupo. Al quitar un usuario
de un grupo, se quitan los derechos del usuario que provenía del grupo. La pertenencia a
grupos es la estrategia preferida.
+ - Inicio de sesión de SQL Server: SQL Server almacena el nombre de usuario y un hash de la
contraseña en la base de datos naster.
+ - Losusuarios de la base de datos independiente autentifican las conexiones de SQL Server
en el nivel de la base de datos. Una base de datos independiente es una base de datos que
está aislada de otras bases de datos y de la instancia de SQL Server (y de la base de datos
master) que hospeda la base de datos. SQL Server admite usuarios de base de datos
independientes para la autenticación de Windows y SQL Server.
Las siguientes recomendaciones y procedimientos recomendados ayudan a proteger
las identidades y los métodos de autenticación:

* Use ré i lal rol n privilegios mínimos para

mejorar la administración de la seguridad.
o - Eshabitual colocar usuarios de Active Directory en grupos de AD; los grupos de AD
deben existir en roles de SQL Server y los roles de SQL Server deben tener los
permisos mínimos necesarios para la aplicación.
+ _ En Azure, use la seguridad con privilegios minimos mediante el uso de controles
de acceso basado en rol (RBAC)
+ - Elija la autenticación de Active Directory en lugar de la de SQL Server siempre
que sea posible y, especialmente, elija Active Directory en vez de almacenar la
seguridad en el nivel de aplicación o base de datos.
o Si un usuario deja la empresa, es fácil deshabilitar la cuenta.
- También es fácil quitar usuarios de grupos cuando los usuarios cambian de roles o
abandonan la organización. La seguridad de grupo se considera un procedimiento
recomendado.
+ _ Use la autenticación multifactor en las cuentas que tienen acceso de nivel de
equipo, incluidas las cuentas que usan RDP para iniciar sesión en la máquina.
Esto ayuda a protegerse contra el robo o las pérdidas de credenciales, ya que la
autenticación basada en contraseña de un solo factor es una forma más débil
de autenticación con credenciales en riesgo de verse comprometidas o dadas
por error.

21
Base de Datos II SQL Server 2014 - Seguridad Clase 8

« - Requerir contraseñas seguras y complejas que no se puedan adivinar fácilmente

y que no se utilicen para otras cuentas o propósitos. Actualice periódicamente
las contraseñas y aplique directivas de Active Directory.
* Las cuentas de servicio administradas de grupo (SMSA) proporcionan
administración automática de contraseñas, administración simplificada de
nombres de entidad de seguridad de servicio (SPN) y la capacidad de delegar la
administración a otros administradores.
o Cuando se usa una gMSA como entidad de servicio, el sistema operativo Windows
administra la contraseña de la cuenta en lugar de recurrir al administrador.
- gMSA actualiza automáticamente las contraseñas de cuenta sin reiniciar los
servicios.
c gMSA reduce el nivel de superficie administrativa y mejora la separación de
tareas.
+ - Minimice los derechos concedidos a la cuenta de AD de DBA. Considere la
posibilidad de separar las tareas que limitan el acceso a la máquina virtual, la
capacidad de iniciar sesión en el sistema operativo, la capacidad de modificar
los registros de errores y auditorías y la capacidad de instalar aplicaciones o
caracteristicas.
+ Considere la posibilidad de quitar cuentas de DBA del rol sysadmin y conceder
CONTROL SERVER a cuentas de DBA en lugar de convertirlas en miembros del
rol sysadmin. El rol de administrador del sistema no respeta n=xy mientras que
CONTROL SERVER sí.

Seleccionar un Modo de Autenticación

SQL Server 2005 soporta dos modos de autenticación, tal y como vimos en el
apartado de instalación: Autenticación Windows y Autenticación Mixta. Cuando
trabajamos en modo Autenticación Windows, que es el predeterminado y aconsejado,
solo los usuarios autorizados de sistema operativo podrán conectarse al servidor SQL
Server. En el modo de Autenticación Windows, podemos proporcionar acceso tanto a
usuarios, como a grupos de sistema operativo.

Para cambiar el Modo de Autenticación, una vez instalada la instancia de SQL Server
Express, lo más sencillo es utilizar la herramienta SQL Server Management Studio
Express. Para ello debes de seguir los siguientes pasos como muestra la figura:
* 1. Inicia SQL Server Management Studio Express desde el Menú Inicio.
* 2. Desde el Object Explorer, haz clic con el botón de la derecha en la instancia y
selecciona Propiedades.
* 3. Desde la pestaña de Security podrás modificar el Modo de Autenticacién
Base de Datos II SQL Server 2014 - Seguridad Clase 8

Nota: Para que este cambio surta efecto deberás de reiniciar el servicio
de SQL Server.
Para decidir que Modo de Autenticación es el más conveniente, deberás de tener en cuenta:

+ El Modo de Autenticación Windows es el más seguro y el recomendado. En este

modo de Autenticación, SQL Server confía en la autenticación realizada por el
Sistema Operativo. En el Modo de Autenticación Windows no viajan contraseñas
por la red, ni será necesario especificarlas en una cadena de conexión.
+ - El Modo de Autenticación Mixto deberemos de utilizarlo únicamente en aquellos
casos en los que, por la estructura de nuestra red, no podamos utilizar
autenticación Windows.
Acceso a una Base de Datos SQL Server

SQL Server utiliza una autenticación en dos pasos: En primer lugar, la cadena de
conexión especifica una autenticación a nivel de Instancia de SQL Server Express.
Una vez se ha autenticado el inicio de sesión, se comprueba si ese inicio de sesión
tiene acceso a la base de datos a la que se pretende acceder. Para ello, SQL Server
mantiene una asociación entre Inicio de Sesión a nivel de Instancia y Usuario a nivel
de Base de Datos.

al
Base de Datos II SQL Server 2014 - Seguridad Clase 8

Crear Inicios de Sesión

El primer paso, para proporcionar acceso a una Base de Datos es crear un inicio de
sesión para el usuario que necesita el acceso. Podemos crear dos tipos de inicio de
sesión: Inicio de Sesión Windows (usuarios o grupos) e Inicios de Sesión SQL Server
(que solo podrán crearse en Autenticación Mixta).

Para crear un Inicio de Sesión Windows:

CREATE LOGIN [EXPRESS\Usuario] FROM WINDOWS

En este ejemplo EXPRESS hace referencia al nombre de Dominio o Equipo en el que

está instalado SQL Server Express y Usuario hace referencia a un usuario de Sistema
Operativo.

Nota: Para que el anterior ejemplo funcione correctamente es necesario

que el usuario Usuario exista a nivel de Sistema Operativo.
Para crear un Inicio de Sesión SQL Server:

‘ CREATE LOGIN SQLUser WITH PASSWORD='Pa$$wOrd'

También podemos utilizar SQL Server Management Studio Express. En Object Explorer,
despliega la Instancia, despliega la carpeta de Security y haz clic en Logins. Si haces
clic con botón de la derecha, New Login... En la figura puedes ver el cuadro de diálogo.

si
Base de Datos II SQL Server 2014 - Seguridad Clase 8

Crear Usuarios de Base de Datos

Una vez hemos creado el Inicio de Sesión para poder acceder a la instancia, debemos
de proporcionar acceso a ese Inicio de Sesión a la base de datos deseada. Para ello
deberemos de crear un usuario en la base de datos y asociarlo al inicio de sesión. El
siguiente cédigo es un ejemplo de este proceso, en el que estamos proporcionando
acceso al Inicio de Sesión [EXPRESS\Usuario] a la base de datos DemoMSDN:

USE DemoMSDN
GO
CREATE USER Usuario FOR LOGIN [EXPRESS\Usuario]

Desde SQL Management Studio podemos realizar esta operación de de formas. Desde
las Propiedades del Inicio de Sesión o en la base de datos, creando un usuario. LA
forma más sencilla es realizarlo desde las propiedades del Inicio de Sesión. Para ello
en las propiedades de un Inicio de Sesión vete a la opción de User Mapping y
selecciona las bases de datos a las que quieres proporcionar acceso. La siguiente
figura muestra dicha opción:
Base de Datos II SQL Server 2014 - Seguridad Clase 8

0]
SOOCOONO

Esquemas de Base de Datos

SQL Server 2005 introduce el concepto ANSI de Esquema, a través del cual podemos
agrupar los objetos de base de datos, tablas, vistas, procedimientos almacenados,
etc., siguiendo el criterio que mejor se adecue a nuestras necesidades. El nombre de
esquema formará parte del nombre completo de los objetos que pertenecen a dicho
esquema. Por ejemplo, si creamos un Esquema denominado Ventas, y dentro de él
una tabla denominada Pedidos, deberemos de calificar la tabla utilizando el nombre
del esquema, al estilo [Link]. Otra de las grandes ventajas del uso de
Esquemas, es que podremos asignar permisos a este nivel, en lugar de tener que
asignar permisos a los diferentes objetos de forma individual. Las siguientes
sentencias ilustran este ejemplo

USE MASTER
GO

-- Creamos un Inicio de Sesión de SQL Server

CREATE LOGIN Alumno WITH PASSWORD='Pa$$wOrd'
GO

-- Creamos una Base de Datos para pruebas

CREATE DATABASE TestDB

7]
Base de Datos II SQL Server 2014 - Seguridad Clase 8

Go |
-- Nos conectamos a la Base de Datos
USE TestDB
GO
-- Creamos el Schema Ventas
CREATE SCHEMA Ventas
Go
--Creamos la Tabla Pedidos en el Esquema Ventas
CREATE TABLE [Link] (idPedido int primary key, FechaPedido
smalidatetime, ¡dCliente int, Estado tinyint)
GO
-- Creamos el usuario alumno enlazado con el Inicio de Sesién Alumno
CREATE USER Alumno FOR LOGIN Alumno
GO
-- Otorgamos el permiso de Select al usuario Alumno sobre el Esquema
Ventas.
GRANT SELECT ON SCHEMA: :Ventas TO Alumno

Nota: Para ejecutar este ejemplo, la instancia de SQL Server Express |

debe de estar ejecutándose en modo Autenticación Mixta.

Linaje de datos e integridad de datos

Mantener registros históricos de los cambios de datos a lo largo del tiempo puede ser
beneficioso para abordar los cambios accidentales en los datos. También puede ser
útil para la auditoría de cambios de aplicación y puede recuperar elementos de datos
cuando un actor malintencionado ha introducido cambios de datos que no estaban
autorizados.
+ Uselas tablas temporales para conservar las versiones de registros a lo largo del tiempo y
para ver los datos tal y como han pasado en el período de vida del registro para
proporcionar una vista histórica de los datos de la aplicación.
+ - Lastablas temporales se pueden usar para proporcionar una versión de la tabla actual en
cualquier momento dado.
Evaluación y herramientas de evaluación de seguridad

Las siguientes herramientas de configuración y evaluación siguientes abordan la

seguridad del área de superficie, identificar oportunidades de seguridad de datos y
proporcionar una evaluación de procedimientos recomendados de la seguridad del
entorno de SQL Server en el nivel de instancia.
Base de Datos II SQL Server 2014 - Seguridad Clase 8

+ - Configuración de área de superficie: se recomienda que habilite solo las características

que necesita el entorno para minimizar el número de características que pueden ser
atacadas por un usuario malintencionado.
+ — Evaluación de vulnerabilidades para SQL Server (SSMS): la evaluación de vulnerabilidades
de SQL es una herramienta de SSMS v17.4+ que ayuda a detectar, realizar un seguimiento
y corregir posibles vulnerabilidades de la base de datos. La evaluación de vulnerabilidades
es una herramienta valiosa para mejorar la seguridad de la base de datos y se ejecuta en el
nivel de base de datos, por base de datos.
+ - Clasificación y detección de datos de SQL (SSMS): es habitual que los DBA administren
servidores y bases de datos y no sean conscientes de la confidencialidad de los datos
contenidos en la base de datos. Clasificación y detección de datos agrega la capacidad de
detectar, clasificar, etiquetar e informar sobre el nivel de confidencialidad de los datos.
Clasificación detección de datos se admite a partir de SSMS 17.5.
Amenazas de SQL comunes

Ayuda a saber cuáles son algunas de las amenazas comunes que ponen en riesgo a
SQL Server:
+ — Inyección de código SQL: es un ataque en el que se inserta código malintencionado en
cadenas que posteriormente se pasan a una instancia de SQL Server para su ejecución.
< El proceso de inyección consiste en finalizar una cadena de texto y anexar un
nuevo comando. Como el comando insertado puede contener cadenas adicionales
que se hayan anexado al mismo antes de su ejecución, el atacante pone fin a la
cadena inyectada con una marca de comentario —-.
SQL Server ejecutará cualquier consulta válida sintácticamente que se reciba.
. u… en cuenta los ataques de canal lateral, el malware y otras amenazas.
Inyección de código SQL
Para minimizar el riesgo de una inyección SQL, tenga en cuenta los siguientes
elementos:
+ - Revise cualquier proceso SQL que construya instrucciones SQL para las vulnerabilidades de
inyección.
+ — Construya instrucciones SQL generadas dinámicamente de forma parametrizada.
* - Los desarrolladores y administradores de seguridad deben revisar todo el código que
llama a EXECUTE, EXEC O sp_executesql.
* No permitir los siguientes caracteres de entrada:
c — ::Delimitador de consultas
< — *: Delimitador de cadenas de datos de caracteres
Delimitador del comentario de una sola línea.
o /* ... */:Delimitadores de comentarios.
c - xp_:Procedimientos almacenados extendidos del catálogo, como xp_crdshe11.
* Noserecomienda usar xp_cndshel1 en ningún entorno de SQL Server.
Use SQLCLR en su lugar o busque otras alternativas debido a los riesgos
que xp_cndshe11 puede introducir.
Base de Datos II SQL Server 2014 - Seguridad Clase 8

* — Valide siempre las entradas del usuario y limpie las salidas de error de que se desbordan y
exponen al atacante.
Riesgos de canal lateral
Para minimizar el riesgo de un ataque de canal lateral, tenga en cuenta lo siguiente:
+ — Asegúrese de que se aplican las revisiones más recientes de la aplicación y del sistema
operativo.
» Enelcaso de las cargas de trabajo hibridas, asegúrese de que se aplican las revisiones de
firmware más recientes para cualquier hardware local.
+ - EnAzure, para cargas de trabajo y aplicaciones altamente confidenciales, puede agregar
protección adicional contra ataques de canal lateral con máquinas virtuales aisladas, hosts
dedicados o mediante el uso de máquinas virtuales de proceso confidencial, como las
series DC y máquinas virtuales que usan los procesadores EPYC AMD de 32 generación.

Amenazas de infraestructura

Tenga en cuenta las siguientes amenazas comunes de infraestructura:

* — Acceso por fuerza bruta: el atacante intenta autenticarse con varias contraseñas en
cuentas diferentes hasta que se encuentra una contraseña correcta.
* - Difusión/Averiguación de contraseña: los atacantes prueban una contraseña diseñada
cuidadosamente con todas las cuentas de usuario conocidas (una contraseña para muchas
cuentas). Si se produce un error en la distribución inicial de contraseñas, lo intentan de
nuevo, usando una contraseña diseñada cuidadosamente diferente, normalmente
esperando una cantidad de tiempo establecida entre los intentos para evitar la detección.
+ - Los ataques de ransomware son un tipo de ataque dirigido en el que se usa malware para
cifrar datos y archivos, lo que impide el acceso a contenido importante. Los atacantes
intenta obtener dinero de las victimas, normalmente en forma de criptomonedas, a
cambio de la clave de descifrado. La mayoría de las virus ransomware comienzan con
mensajes de correo electrónico con datos adjuntos que intentan instalar ransomware o
sitios web que hospedan kits de vulnerabilidades que intentan usar vulnerabilidades en
exploradores web y otro software para instalar ransomware.
Riesgos de contraseña
Dado que no quiere que los atacantes adivinen fácilmente nombres de cuenta o
contraseñas, los pasos siguientes ayudan a reducir el riesgo de que se descubran
contraseñas:

+ - Cree una cuenta de administrador local única que no se llame Administrador.

+ - Use contraseñas seguras complejas para todas sus cuentas. Para más información sobre
cómo crear una contraseña segura, vea el articulo Crear una contraseña segura.
* Deforma predeterminada, Azure selecciona la Autenticación de Windows durante la
instalación de la máquina virtual de SQL Server. Por lo tanto, el inicio de sesión de SA está
deshabilitado y el programa de instalación asigna una contraseña. Se recomienda no usar

10|
Base de Datos II SQL Server 2014 - Seguridad Clase 8

ni habilitar el inicio de sesión de SA. Si debe tener un inicio de sesión de SQL, use una de
las estrategias siguientes:
o Cree una cuenta de SQL con un nombre único que sea miembro de
sysadmin. Puede hacerlo desde el portal si habilita Autenticación de
SQL durante el aprovisionamiento.
- Sitiene que usar el inicio de sesión de SA, habilite el inicio de sesión
después del aprovisionamiento y asigne una nueva contraseña segura.
Riesgos de ransomware

Tenga en cuenta lo siguiente para minimizar los riesgos de ransomware:

+ - Lamejor estrategia para protegerse contra ransomware es prestar especial atención a las
vulnerabilidades de RDP y SSH. Además, tenga en cuenta las recomendaciones siguientes:
c Usafirewalls y bloqueo de puertos
c Asegurarse de que se aplican las actualizaciones de seguridad del sistema
operativo y de la aplicación más recientes
o Usar cuentas de servicio administradas de grupo (§MSA)
c Limitar el acceso a las máquinas virtuales
c Requerir acceso Just-In-Time (IIT) y Azure Bastion
c - Mejorar la seguridad del área de superficie evitando la instalación de
herramientas como sysinternals y SSMS en el equipo local
o - Evitar instalar características de Windows, roles y habilitar servicios que no son
necesarios
c - Además, debe haber una copia de seguridad completa normal programada que
esté protegida por separado de una cuenta de administrador común para que no
pueda eliminar copias de las bases de datos.
Entidades de seguridad y seguridad de objetos de base de datos

Las entidades de seguridad son los individuos, grupos y procesos que tienen acceso a
SQL Server. Los "elementos protegibles" son el servidor, la base de datos y los
objetos incluidos en la base de datos. Cada uno de estos elementos dispone de un
conjunto de permisos que pueden configurarse para reducir el área expuesta de SQL
Server. En la tabla siguiente se incluye información sobre las entidades de seguridad
y los elementos protegibles.
Entidades de seguridad (motor de base de datos)
Las entidades de seguridad son entidades que pueden solicitar recursos de SQL
Server. Igual que otros componentes del modelo de autorización de SQL Server , las
entidades de seguridad se pueden organizar en jerarquías. El ámbito de influencia de
una entidad de seguridad depende del ámbito de su definición: Windows, servidor o
base de datos; y de si la entidad de seguridad es indivisible o es una colección. Un
Inicio de sesión de Windows es un ejemplo de entidad de seguridad indivisible y un
Grupo de Windows es un ejemplo de una del tipo colección. Toda entidad de
seguridad tiene un identificador de seguridad (SID). Este tema se aplica a todas las
versiones de SQL Server, pero hay algunas restricciones en las entidades de
seguridad a nivel de servidor de SQL Database o Azure Synapse Analytics.
11|
Base de Datos II SQL Server 2014 - Seguridad Clase 8

Entidades de seguridad de nivel de SQL Server

+ -
Inicio de sesión para la autenticación de SQL Server
+ -
Inicio de sesión con autenticación de Windows para un usuario de Windows
+ -
Inicio de sesión con autenticación de Windows para un grupo de Windows
+ -
Inicio de sesion de autenticación de Microsoft Entra para un usuario de Microsoft
Entra
+ - Inicio de sesión de autenticación de Microsoft Entra para un grupo de Microsoft
Entra
* Rol de servidor

Entidades de seguridad de nivel de bases de datos

+ — Usuario de la base de datos.

* - Rol de base de datos.
+ - Rol de aplicación.
Inicio de sesión sa

El inicio de sesión de SQL Server sa es una entidad de seguridad a nivel de servidor.

Se crea de forma predeterminada cuando se instala una instancia. A partir de SQL
Server 2005 (9.x), la base de datos predeterminada de sa es master. Es un cambio
de comportamiento con respecto a versiones anteriores de SQL Server. El inicio de
sesión sa es miembro del rol fijo de nivel de servidoreysadnin. Este inicio de sesión
sa tiene todos los permisos en el servidor y no puede limitarse. Además, sa no se
puede quitar, pero puede deshabilitarse para que nadie lo emplee.
Usuario y esquema dbo

El usuario dbo es una entidad de seguridad de usuario especial que hay en cada base
de datos. Todos los administradores de SQL Server, los miembros del rol fijo de
servidor syeadmin, el inicio de sesión sa y los propietarios de la base de datos
especifican las bases de datos como el usuario 4bo. El usuario dbo tiene todos los
permisos en la base de datos y no se limitar ni quitar. dbo representa el propietario
de la base de datos, pero la cuenta de usuario dbo no es lo mismo que el rol fijo de
base de datos ab_owner, mientras que el rol fijo de base de datos ab_cuner no es lo
mismo que la cuenta de usuario que se registra como el propietario de la base de
datos.
El usuario abo tiene la propiedad del esquema dbo. El esquema dbc es el
predeterminado para todos los usuarios, salvo que se especifique otro. El esquema
dbo no puede quitarse.
Rol público de base de datos y de servidor

Cada inicio de sesión pertenece al rol fijo de servidor public y cada usuario de base
de datos pertenece al rol de base de datos public. Cuando a un usuario o inicio de
sesión no se le han concedido ni denegado permisos concretos para un elemento
12|
Base de Datos II SQL Server 2014 - Seguridad Clase 8

protegible, hereda los permisos para ese elemento concedidos a public. El rol fijo de
servidor public y el de base de datos public no pueden quitarse. Sin embargo,
puede revocar los permisos de los roles pub1:c. Hay muchos de los permisos que se
asignan a los roles public de forma predeterminada. La mayoría de estos permisos
son necesarios para realizar operaciones rutinarias en la base de datos; el tipo de
tareas que todo el mundo debe poder hacer. Tenga cuidado al revocar permisos desde
el usuario o el inicio de sesión público, ya que afectará a todos los inicios de sesión y
usuarios. Normalmente, no debe denegar permisos a public, ya que la instrucción
deny invalida cualquier instrucción grant que podrían crear para los usuarios.
INFORMATION_SCHEMA, y usuarios y esquemas sys
Todas las bases de datos incluyen dos entidades que aparecen como usuarios en las
vistas de catálogo: INFORMATION SCHEMA y ays. Estas entidades son necesarias para
uso interno por parte del motor de base de datos. No se pueden modificar ni quitar.

Inicios de sesión de SQL Server basados en certificados

Las entidades de seguridad de servidor con nombres incluidos entre signos de número
dobles (##) son exclusivamente para uso interno del sistema. Las siguientes entidades de
seguridad se crean a partir de certificados cuando se instala SQL Server, y no deben
eliminarse.
» ##MS_SQLResourceSigningCertificate##
» ##MS_SQLReplicationSigningCertificate##
##MS_SQLAuthenticatorCertificate##
#MS_AgentSigningCertificate#t#
#MS_PolicyEventProcessingLogin##
#MS_PolicySigningCertificate##
##MS_PolicyTsqlExecutionLogin##
Estas cuentas principales no tienen contraseñas que los administradores puedan cambiar, ya
que se basan en certificados emitidos a Microsoft.
Usuario guest
Cada base de datos incluye un usuario quest. Los permisos concedidos al usuario
guest se aplican a todos los usuarios que tienen acceso a la base de datos, pero no
disponen de una cuenta en la base de datos. No se puede quitar el usuario guest,
pero se puede deshabilitar si se revoca su permiso CONNECT. El permiso CONNECT se
puede revocar si se ejecuta REVOKE CONNECT FROM GUEST; en cualquier base de datos
que no sea master Ni tempdb.

13|
Base de Datos II SQL Server 2014 - Seguridad Clase 8

Elementos protegibles
Los elementos protegibles son los recursos cuyo acceso es regulado por el sistema de
autorización del motor de base de datos SQL Server. Por ejemplo, una tabla es un
elemento protegible. Algunos elementos protegibles pueden estar incluidos en otros,
con lo que se crean jerarquías anidadas denominadas "ámbitos" que a su vez se
pueden proteger. Los ámbitos protegibles son servidor, base de datosy esquema.
Ámbito protegible: servidor

El ámbito protegible servidor contiene los siguientes valores que puede proteger:
+ - grupo de disponibilidad
+ - Punto de conexión
+ - Iniciar sesión
* - Rol del servidor
* Base de datos
Ámbito protegible: base de datos

El ámbito protegible base de datos contiene los siguientes valores que puede
proteger:

+ Rol de aplicación
+ Ensamblado
+ - Clave asimétrica
+ Certificate
* Contrato
+ Catálogo de texto completo
+ _ Lista de palabras irrelevantes de texto completo
* Tipo de mensaje
+ - Enlace de servicio remoto
* (Base de datos) Rol
* Ruta
* Esquema
+ Lista de propiedades de búsqueda
* Service
+ - Clave simétrica
* - Usuario
Ámbito protegible: esquema

El ámbito protegible esquema contiene los siguientes valores que se pueden

proteger:

+ Tipo
+ - Colección de esquemas XML
+ - Objeto: la clase de objeto tiene los miembros siguientes:
o Agregada
o Función
z
Base de Datos II SQL Server 2014 - Seguridad Clase 8

Procedimiento
Cola

0000
Synonym (Sinónimo)
Tabla
o Ver
o Tabla externa

Controlar el acceso a un elemento protegible

La entidad que recibe el permiso para un elemento protegible se denomina "entidad

de seguridad”. Las entidades de seguridad más comunes son inicios de sesión y
usuarios de la base de datos. El acceso a elementos protegibles se controla mediante
la concesión o denegación de permisos o con la incorporación de inicios de sesión y
usuarios a roles con acceso.
Jerarquía de permisos (motor de base de datos)
El motor de base de datos administra un conjunto jerárquico de entidades que se
pueden proteger mediante permisos. Estas entidades se conocen como elementos
protegibles. Los protegibles más prominentes son los servidores y las bases de datos,
pero los permisos discretos se pueden establecer en un nivel mucho más específico.
SQL Server regula las acciones de las entidades de seguridad en los elementos
protegibles comprobando que se les ha concedido los permisos adecuados.
En la ilustracion siguiente se muestran las relaciones entre las jerarquías de permisos
del motor de base de datos.
El sistema de permisos funciona igual en todas las versiones de SQL Server, SQL
Database, Azure Synapse Analytics y Analytics Platform System; sin embargo, algunas
características no están disponibles en todas las versiones. Por ejemplo, el permiso de
nivel de servidor no se puede configurar en productos de Azure.

15|
Base de Datos 11 SQL Server 2014 - Seguridad Clase 8

Microsoft SQL Ser

Trabajar con permisos

Los permisos se pueden manipular con las conocidas consultas GRANT, DENY y
REVOKE de Transact-SQL.
Cifrado y certificados

El cifrado no resuelve los problemas de control de acceso. Sin embargo, mejora la

seguridad debido a que limita la pérdida de datos, incluso en el caso poco probable de
que se superen los controles de acceso. Por ejemplo, si el equipo host de base de
datos no está configurado correctamente y un usuario malintencionado obtiene datos
confidenciales, como números de tarjetas de crédito, esa información robada podría

16|
Base de Datos II SQL Server 2014 - Seguridad Clase 8

resultar inservible si está cifrada. La tabla siguiente contiene más información acerca
del cifrado en SQL Server.

Jerarquía de cifrado

SQL Server cifra los datos con una infraestructura de cifrado jerárquico y administración de
claves. Cada capa cifra la capa inferior utilizando una combinación de certificados, claves
asimétricas y claves simétricas. Las claves asimétricas y las claves simétricas pueden estar
almacenadas fuera de SQL Server en un módulo de Administración extensible de claves
(EKM).
La siguiente ilustración muestra que cada nivel de la jerarquía de cifrado cifra el nivel que
tiene por debajo y muestra las configuraciones de cifrado más comunes. El acceso al
principio de la jerarquía se suele proteger mediante una contraseña.

17|
Base de Datos 11 SQL Server 2014 - Seguridad Clase 8

Tenga presente los conceptos siguientes:

Para obtener el máximo rendimiento, cifre los datos utilizando claves simétricas en
lugar de certificados o claves asimétricas.
Las claves maestras de base de datos se protegen mediante la clave maestra de
servicio. El programa de instalación de SQL Server crea la clave maestra de
servicio, que se cifra con la API de protección de datos de Windows (DPAPI).
Hay otras jerarquías de cifrado que apilan niveles adicionales.
El módulo de Administración extensible de claves (EKM) mantiene las claves
simétricas o asimétricas fuera de SQL Server.
El Cifrado de datos transparente (TDE) debe utilizar una clave simétrica
denominada clave de cifrado de base de datos que se protege bien mediante un
certificado protegido por la clave maestra de base de datos de la base de datos
maestra o bien mediante una clave asimétrica almacenada en una EKM.
La clave muestra de servicio y todas las claves maestras de base de datos son claves
simétricas.

18|
Base de Datos II SQL Server 2014 - Seguridad Clase 8

Mecanismos de cifrado

SQL Server ofrece los mecanismos siguientes para el cifrado:

« - Funciones de Transact-SQL
+ - Claves asimétricas
+ - Claves simétricas
» - Certificados
+ - Cifrado de datos transparente
Funciones de Transact-SQL
Los elementos individuales se pueden cifrar a medida que se insertan o actualizan
utilizando las funciones de Transact-SQL.

Certificados

Un certificado de clave pública, normalmente denominado solo certificado, es una

instrucción firmada digitalmente que enlaza el valor de una clave pública con la
identidad de la persona, dispositivo o servicio que tiene la clave privada
correspondiente. Las entidades certificadoras son las encargadas de emitir y firmar los
certificados. La entidad que recibe un certificado de una CA es el sujeto de ese
certificado. Por lo general, los certificados contienen la siguiente información.
* Laclave pública del sujeto.
* - La información que identifica al sujeto, como el nombre y la direccion de correo
electrónico.
+ - El periodo de validez. Es decir, el periodo de tiempo durante el que el
certificado se considera válido.
Un certificado solo es válido durante el periodo de tiempo que se especifica en
el mismo; todos los certificados contienen una fecha Válido desde y otra
Válido hasta . Estas fechas establecen los límites del periodo de validez.
Cuando el periodo de validez de un certificado ha transcurrido, es necesario que
el sujeto del certificado expirado solicite uno nuevo.
* - Información de identificador del emisor.
* Lafirma digital del emisor.

Esta firma da fe de la validez de las obligaciones entre la clave pública y la

información de identificador del sujeto. (El proceso de firmar digitalmente la
informacién conlleva transformar la información, así como cierta información
privada que conserva el remitente, en una etiqueta denominada firma.)
Una de las principales ventajas de los certificados es que liberan a los hosts de la
necesidad de establecer contraseñas para sujetos individuales. En su lugar, el host
simplemente establece la confianza en un emisor de certificados, que a continuación
puede firmar un número ilimitado de certificados.

19|
Base de Datos II SQL Server 2014 - Seguridad Clase 8

Cuando un host, por ejemplo, un servidor web seguro, designa a un emisor como
entidad emisora raíz de confianza, el host implicitamente confía en las directivas que
el emisor ha utilizado para establecer las obligaciones de los certificados que emite.
En efecto, el host confía en que el emisor ha comprobado la identidad del sujeto del
certificado. Un host designa a un emisor como entidad emisora raíz de confianza
presentando el certificado autofirmado del emisor, que contiene la clave pública de
éste, en el almacén de certificados de la entidad de certificación raíz de confianza del
equipo host. Las entidades de certificación intermedias o subordinadas solo son de
confianza si tienen una ruta válida de certificación procedente de una entidad de
certificación raíz.
El emisor puede revocar un certificado antes de que expire. La revocación cancela las
obligaciones que una clave pública tiene con una identidad que se exprese en el
certificado. Cada emisor mantiene una lista de revocación de certificados que los
programas pueden utilizar cuando estén comprobando la validez de un certificado
determinado.
Los certificados autofirmados que se crean con SQL Server cumplen el estándar X.509
y son compatibles con los campos de X.509 v1.

Claves asimétricas

Una clave asimétrica se compone de una clave privada y su correspondiente clave

pública. Cada clave puede descifrar los datos que cifra la otra. El cifrado y descifrado
asimétricos consumen una cantidad de recursos relativamente elevada, pero
proporcionan un nivel de seguridad superior al del cifrado simétrico. Una clave
asimétrica se puede utilizar para cifrar una clave simétrica para almacenar en una
base de datos.
Claves simétricas

Una clave simétrica es una clave que se utiliza para el cifrado y el descifrado. El
cifrado y el descifrado con una clave simétrica son más rápidos y adecuados para
usarlos de forma rutinaria con datos confidenciales de una base de datos.

Cifrado de datos transparente

El Cifrado de datos transparente (TDE) es un caso especial de cifrado que usa una
clave simétrica. TDE cifra una base de datos completa utilizando la clave simétrica
denominada clave de cifrado de base de datos. Otras claves o certificados que se
protegen bien mediante la clave maestra de base de datos o bien mediante una clave
asimétrica almacenadas en un módulo EKM protegen la clave de cifrado de base de
datos.
Configuración del Motor de base de datos de SQL Server para cifrar
conexiones

Puede cifrar todas las conexiones entrantes a SQL Server o habilitar el cifrado solo
para un conjunto específico de clientes. En cualquiera de estos escenarios, primero
20|
Base de Datos II SQL Server 2014 - Seguridad Clase 8

debe configurar SQL Server para usar un certificado que cumpla los requisitosde
certificado para SQL Server, antes de realizar pasos adicionales en el equipo servidor
0 en los equipos cliente para cifrar los datos.
En este artículo se describe cómo configurar SQL Server para certificados (paso 1) y
cómo cambiar la configuración de cifrado de la instancia de SQL Server (paso 2).
Ambos pasos son necesarios para cifrar todas las conexiones entrantes a SQL Server
cuando se usa un certificado de una entidad comercial pública. Para otros escenarios,
consulte Casos especiales para cifrar conexiones a SQL Server.
Paso 1: Configuración de SQL Server para usar certificados

Si quiere configurar SQL Server para usar los certificados que se describen en
Requisitos de certificado para SQL Server, siga estos pasos:

1. Instale el certificado en el equipo que ejecuta SQL Server.

2. Configure SQL Server para usar el certificado instalado.
En función de la versión del Administrador de configuración de SQL Server al que
tenga acceso en el equipo con SQL Server, use uno de los procedimientos siguientes
para instalar y configurar la instancia de SQL Server.
Equipos con Administrador de configuración de SQL Server para SQL Server 2019 y
versiones posteriores

A partir de SQL Server 2019 (15.x), la administración de certificados está integrada

en el Administrador de configuración de SQL Server y se puede usar con versiones
anterlores de SQL Server. Para agregar un certificado en una instancia de SQL Server,
en una configuración de clúster de conmutación por ermr 0 en una configuración de
grupo de disponibilidad, consulte Administr:
configuración de SQL Server). El Administrador de cunf¡gnraclón simplifica
considerablemente la administración de certificados al encargarse de instalar el
certificado y configurar SQL Server para usar el certificado instalado con tan solo unos
pocos pasos.
Los certificados se almacenan localmente para los usuarios del equipo. Para instalar
un certificado de modo que lo use SQL Server, debe ejecutar el Administrador de
configuración de SQL Server con una cuenta que tenga privilegios de administrador
local.
Puede instalar temporalmente una edición Express de SQL Server 2019 (15.x) o una
versión posterior para usar el Administrador de configuración de SQL Server, que
admite la administración de certificados integrada.

21|
Base de Datos II SQL Server 2014 - Seguridad Clase 8

Equipos con Administrador de configuración de SQL Server para SQL Server 2017 y
versiones anteriores

Si usa SQL Server 2017 (14.x) o una versión anterior, y el Administrador de

configuracién de SQL Server para SQL Server 2019 (15.x) no está disponible, siga
estos pasos para instalar y configurar el certificado en el equipo con SQL Server:
1. En el menú Inicio, seleccione Ejecutar; en el cuadro Abrir, escriba MMC y seleccione
Aceptar.
En el menú Archivo de la consola MMC, seleccione Agregar o quitar complemento.
En el cuadro de diálogo Agregar o quitar complementos, seleccione Certificados y
Agregar.
En el cuadro de diálogo Complemento Certificados, seleccione Cuenta de equipo y, luego,
seleccione Siguiente>Finalizar.
En el cuadro de diálogo Agregar o quitar complementos, seleccione Aceptar.
u

En la consola MMC, expanda Certificados (equipo local)>Personal, haga clic con el botón
derecho en Certificados, seleccione Todas las tareas y, luego, seleccione Importar.
Finalice el Asistente para importar certificados para agregar un certificado al equipo.
E

En la consola MMC, haga clic con el botón derecho en el certificado importado, seleccione
Todas las tareas y, luego, seleccione Administrar claves privadas. En el cuadro de diálogo
Seguridad, agregue el permiso de lectura para la cuenta de usuario que usa la cuenta de
servicio de SQL Server.
En Administrador de configuración de SQL Server, expanda Configuración de red de
SQL Server, haga clic con el botón derecho en Protocolos de <instancia de servidor> y
seleccione Propiedades.
10. En el cuadro de didlogo Protocolos de <nombre de instancia> Propiedades, en la pestaña
Certificado, seleccione el certificado que quiera en el menú desplegable del cuadro
Certificado y, después, haga clic en Aceptar.
1 Si necesita que todas las conexiones a SQL Server se cifren, consulte Paso 2: Configuración
H

de las opciones de cifrado en SQL Server. Si solo quiere habilitar el cifrado para clientes
específicos, reinicie el servicio SQL Server y consulte Casos especiales para cifrar
conexiones a SQL Server.
Paso 2: Configuración de las opciones de cifrado en SQL Server

Los pasos siguientes solo son necesarios si quiere forzar las comunicaciones cifradas para
todos los clientes:

En el Administrador de configuración de SQL Server, expanda Configuración de

red de SQL Server, haga clic con el botón derecho en Protocolos de <instancia de
servidor> y seleccione Propiedades.
En la pestaña Marcas, en el cuadro ForceEneryption, seleccione Sí y, a
continuación, seleccione Aceptar para cerrar el cuadro de diálogo.
Reinicie el servicio SQL Server.
Base de Datos II SQL Server 2014 - Seguridad Clase 8

Cifrado de paquetes de inicio de sesión frente al cifrado de paquetes de

datos

En lineas generales, hay dos tipos de paquetes en el tráfico de red entre una
aplicación cliente de SQL Server y SQL Server: paquetes de credenciales (paquetes de
inicio de sesión) y paquetes de datos. Al configurar el cifrado (ya sea del lado servidor
0 del lado cliente), ambos tipos de paquetes siempre se cifran. Pero, incluso cuando
no se configura el cifrado, las credenciales (en el paquete de inicio de sesión) que se
transmiten cuando una aplicación cliente se conecta a SQL Server siempre se cifran.
SQL Server usa un certificado que cumple los requisitos de certificado de una entidad
de certificación de confianza si está disponible. Este certificado lo configura
manualmente el administrador del sistema mediante uno de los procedimientos ya
descritos en el artículo, o bien puede estar presente en el almacén de certificados del
equipo con SQL Server.
Certificados autofirmados generados por SQL Server

SQL Server usa un certificado de una entidad de certificación de confianza si está

disponible para cifrar paquetes de inicio de sesión. Si no hay instalado un certificado
de confianza, SQL Server genera un certificado autofirmado (certificado de reserva)
durante el inicio y lo usa para cifrar las credenciales. Este certificado autofirmado
contribuye a aumentar la seguridad, pero no protege contra la suplantación de
identidad por el servidor. Si se usa el certificado autofirmado y el valor de la opción
ForceEncryption está establecido en S, todos los datos transmitidos a través de una
red entre SQL Server y la aplicación cliente se cifran con el certificado autofirmado.

Al usar un certificado autofirmado, SQL Server registra el mensaje siguiente en el

registro de errores:

Se cargó correctamente un certificado generado automáticamente para cifrado.

SQL Server 2016 (13.x) y las versiones anteriores usan el algoritmo SHA1. Pero el
algoritmo SHA1 y muchos algoritmos más antiguos han quedado en desuso a partir
de SQL Server 2016 (13.x).
En estos entornos, si usa el certificado autofirmado generado automáticamente por
SQL Server, ya sea solo para el protocolo de enlace previo al inicio de sesión o para el
cifrado de todas las comunicaciones de servidor-cliente, el software de detección de
vulnerabilidades o las directivas de seguridad del software o de la empresa podrían
marcar este uso como un problema de seguridad. Tiene las siguientes opciones para
estos escenarios:

+ - Cree un certificado autofirmado o un certificado de terceros que use algoritmos de cifrado

más seguros y configure SQL Server para usar este nuevo certificado.
* — Puesto que ahora comprende el motivo de la marca, puede omitir el mensaje (no
recomendado).
+ - Actualice a SQL Server 2017 (14.x) o una versión posterior que use un algoritmo hash más
seguro (SHA256) para los certificados autofirmados.

23|
Base de Datos II SQL Server 2014 - Seguridad Clase 8

Script de PowerShell para crear un certificado autofirmado para

SQL Server
El siguiente fragmento de código se puede usar para crear un certificado autofirmado
en un equipo que ejecuta SQL Server. El certificado cumple los requisitos de cifrado
para una instancia de SQL Server independiente y se guarda en el almacén de
certificados del equipo local (debe iniciarse PowerShell como administrador):
# Define parameters
$certificateParams = O(
Type = "SSLServerAuthentication"
Subject = "CN=$env:COMPUTERNAME"
DnsName = @("{0}" -f [[Link]: GetHostByName($env:computerName).HostName,
“localhost')
KeyAlgorithm = "RSA"
KeyLength = 2048
HashAlgorithm = "SHA256"
TextExtension = "[Link]=(text)[Link].[Link].1"
NotAfter = (Get-Date).AddMonths(36)
KeySpec = "KeyExchange"
Provider = "Microsoft RSA SChannel Cryptographic Provider"
CertStoreLocation = "cert:\LocalMachine\My"
)
# Call the cmdlet
New-SelfSignedCertificate @certificateParams
Comprobación del cifrado de red

Para comprobar que el cifrado de red está configurado y habilitado correctamente,

ejecute la siguiente consulta de Transact-SQL:
USE [master];
60
SELECT DISTINCT (encrypt_option)
FROM sys.dm_exec_connections;
Go
La columna encrypt_option es un valor booleano que indica si el cifrado está
habilitado para esta conexión. Si el valor es TRUE, la conexión está cifrada de forma
segura. Si el valor es rALsE, la conexión no está cifrada de forma segura.
Comportamiento del certificado de SQL Server con permisos
El servicio SQL Server detecta y usa automáticamente el certificado para el cifrado si
se cumplen todas las condiciones siguientes:
+ - Elcertíficado tiene un asunto que contiene el FQDN de la máquina

24|
Base de Datos II SQL Server 2014 - Seguridad Clase 8

* El certificado se instala en el almacén de certificados del equipo local

* - Alacuenta de servicio de SQL Server se le concede acceso a la clave privada del certificado

Este uso se produce incluso si el certificado no está seleccionado en el Administrador

de configuración de SQL Server.
Para invalidar este comportamiento:

e - Configure otro certificado que se usará en el Administrador de configuración de

SQL Server
+ - Quite los permisos de la cuenta de servicio de SQL Server al certificado no
deseado

Funciones y vistas de catálogo de seguridad de SQL Server

El motor de base de datos expone información de seguridad en varias vistas y
funciones que se optimizan en cuanto a rendimiento y utilidad. En la tabla siguiente
se incluye más información acerca de las funciones y vistas de seguridad.
Vistas de catálogo de seguridad (Transact-SQL)

La información de seguridad se publica en vistas de catálogo que se optimizan por

rendimiento y utilidad. Cuando sea posible, use las siguientes vistas de catálogo para
tener acceso a metadatos del catálogo. Vistas de catálogo de seguridad de SQL
Server que devuelven información sobre los permisos de nivel de base de datos y de
servidor, entidades de seguridad, roles, etc. También hay vistas de catálogo que
proporcionan información acerca de las claves de cifrado, los certificados y las
credenciales.
Funciones de seguridad (Transact-SQL)
Las funciones de seguridad de SQL Server, que devuelven información sobre el
usuario, los permisos y los esquemas actuales.

Funciones y vistas de administración dinámica relacionadas con la

seguridad (Transact-SQL)
Vistas de administración dinámica de seguridad de SQL Server

25|