Eventos
31 mar, 23 - 2 abr, 23
Evento de aprendizaje de SQL, Fabric y Power BI más grande. 31 de marzo – 2 de abril. Use el código FABINSIDER para ahorrar $400.
Regístrate hoyEste explorador ya no se admite.
Actualice a Microsoft Edge para aprovechar las características y actualizaciones de seguridad más recientes, y disponer de soporte técnico.
Se aplica a: SQL Server: solo Windows
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 debe configurar SQL Server para que use un certificado que cumpla los Requisitos de certificado para SQL Server antes de realizar pasos adicionales en el equipo servidor o los equipos cliente para cifrar los datos.
Nota
Este artículo se aplica a SQL Server en Windows. Para configurar SQL Server en Linux para cifrar conexiones, consulte Especificar la configuración de TLS.
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.
Si quiere configurar SQL Server para usar los certificados que se describen en Requisitos de certificado para SQL Server, siga estos pasos:
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.
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 anteriores de SQL Server. Para agregar un certificado en una instancia de SQL Server, en una configuración de clúster de conmutación por error o en una configuración de grupo de disponibilidad, consulte Administración de certificados (Administrador de configuración de SQL Server). El Administrador de configuració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.
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:
Nota
Para instalar certificados en la configuración del grupo de disponibilidad, repita el procedimiento anterior en cada nodo del grupo de disponibilidad, empezando por el nodo principal.
Importante
La cuenta de servicio de SQL Server debe tener permisos de lectura en el certificado que se usa para forzar el cifrado en la instancia de SQL Server. En el caso de una cuenta de servicio sin privilegios, será necesario agregar permisos de lectura al certificado. Si no lo hace, se puede producir un error en el reinicio del servicio SQL Server.
El certificado que SQL Server emplea para cifrar las conexiones se especifica en la siguiente clave del Registro:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.x\MSSQLServer\SuperSocketNetLib\Certificate
Esta clave contiene una propiedad del certificado conocida como huella digital, que identifica cada certificado del servidor. En un entorno agrupado, esta clave se establece en Null
aunque exista el certificado correcto en el almacén. Para resolver este problema, debe realizar estos pasos adicionales en cada uno de los nodos del clúster después de instalar el certificado en cada nodo:
Vaya al almacén de certificados donde se almacena el certificado de nombre de dominio completo (FQDN). En la página de propiedades del certificado, vaya a la pestaña Detalles y copie el valor de la huella digital del certificado en una ventana del Bloc de notas.
Quite los espacios entre los caracteres hexadecimales del valor de la huella digital en el Bloc de notas.
Inicie el Editor del Registro, navegue a la siguiente clave del Registro y pegue el valor del paso 2:
HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\<instance>\MSSQLServer\SuperSocketNetLib\Certificate
Si el servidor virtual de SQL está actualmente en este nodo, conmute por error a otro nodo del clúster y reinicie el nodo donde se produjo el cambio del Registro.
Repita este procedimiento en todos los nodos.
Advertencia
Una modificación incorrecta del Registro puede provocar daños graves en el sistema. Antes de efectuar cambios en el Registro, es recomendable que realice una copia de seguridad de los datos importantes del equipo.
Nota
SQL Server 2008 R2 (10.50.x) y SQL Server 2008 R2 (10.50.x) Native Client (SNAC) admiten certificados comodín. SNAC ha quedado en desuso y se ha reemplazado por Microsoft OLE DB Driver for SQL Server y Microsoft ODBC Driver for SQL Server. Es posible que otros clientes no admitan los certificados comodín.
El certificado comodín no se puede seleccionar con el Administrador de configuración de SQL Server. Para usar un certificado comodín, debe editar la clave del Registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQLServer\SuperSocketNetLib
y escribir la huella digital del certificado, sin espacios en blanco, en el valor Certificado.
Nota
Si desea utilizar el cifrado con un clúster de conmutación por error, debe instalar el certificado del servidor con el nombre DNS completo del servidor virtual en todos los nodos del clúster de conmutación por error. Puede establecer el valor de la opción ForceEncryption en el cuadro de propiedades Protocolos para virtsql de Configuración de red de SQL Server en Sí.
Al crear conexiones cifradas para un indexador de Azure Search en SQL Server en una máquina virtual de Azure, consulte Conexiones de indexador a una instancia de SQL Server en una máquina virtual de Azure.
Los pasos siguientes solo son necesarios si quiere forzar las comunicaciones cifradas para todos los clientes:
Nota
Algunos escenarios de certificado podrían requerir la implementación de pasos adicionales en el equipo cliente y en la aplicación cliente para garantizar las conexiones cifradas entre el cliente y el servidor. Para obtener más información, consulte Casos especiales para cifrar conexiones a SQL Server.
En líneas 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 o 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.
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). Para obtener más información, consulte Características del motor de base de datos en desuso en 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:
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 = @{
Type = "SSLServerAuthentication"
Subject = "CN=$env:COMPUTERNAME"
DnsName = @("$($env:COMPUTERNAME)", $([System.Net.Dns]::GetHostEntry('').HostName), 'localhost')
KeyAlgorithm = "RSA"
KeyLength = 2048
HashAlgorithm = "SHA256"
TextExtension = "2.5.29.37={text}1.3.6.1.5.5.7.3.1"
NotAfter = (Get-Date).AddMonths(36)
KeySpec = "KeyExchange"
Provider = "Microsoft RSA SChannel Cryptographic Provider"
CertStoreLocation = "cert:\LocalMachine\My"
}
# Call the cmdlet
New-SelfSignedCertificate @certificateParams
Para comprobar que el cifrado de red está configurado y habilitado correctamente, ejecute la siguiente consulta de Transact-SQL:
USE [master];
GO
SELECT DISTINCT (encrypt_option)
FROM sys.dm_exec_connections
WHERE net_transport <> 'Shared memory';
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 FALSE
, la conexión no está cifrada de forma segura.
El servicio SQL Server detecta y usa automáticamente el certificado para el cifrado si se cumplen todas las condiciones siguientes:
Este uso se produce incluso si el certificado no está seleccionado en el Administrador de configuración de SQL Server.
Para invalidar este comportamiento:
Configure otro certificado que se usará en el Administrador de configuración de SQL Server
o
Quite los permisos de la cuenta de servicio de SQL Server al certificado no deseado
Eventos
31 mar, 23 - 2 abr, 23
Evento de aprendizaje de SQL, Fabric y Power BI más grande. 31 de marzo – 2 de abril. Use el código FABINSIDER para ahorrar $400.
Regístrate hoyCursos
Módulo
Protección de los datos en tránsito y en reposo - Training
Protección de los datos en tránsito y en reposo
Certificación
Microsoft Certified: Azure Database Administrator Associate - Certifications
Administre una infraestructura de base de datos de SQL Server para bases de datos relacionales locales e híbridas en la nube mediante las ofertas de bases de datos relacionales PaaS de Microsoft.