Seguridad de la capa de transporte y certificados digitales
En este artículo se describen los detalles sobre el protocolo Seguridad de la capa de transporte (TLS) y los certificados digitales.
Seguridad de la capa de transporte (TLS)
Los protocolos TLS y SSL se encuentran entre la capa de protocolo de aplicación y la capa TCP/IP, donde pueden proteger y enviar datos de aplicación a la capa de transporte. Los protocolos TLS/SSL usan algoritmos de un conjunto de cifrado para crear claves y cifrar información. El cliente y el servidor negocian la versión del protocolo y el conjunto de cifrado que se usarán para el cifrado durante la fase inicial de conexión (inicio de sesión previo) del establecimiento de la conexión. En el protocolo de enlace TLS siempre se prefiere la versión de TLS más alta admitida. Para comprobar las versiones de protocolos TLS compatibles con diferentes versiones de sistemas operativos Windows, consulte Protocolos en TLS/SSL (Schannel SSP). Se han notificado varias vulnerabilidades conocidas en SSL y versiones anteriores de TLS. Se recomienda actualizar a TLS 1.2 para una comunicación segura.
SQL Server puede usar TLS para cifrar los datos transmitidos a través de una red entre una instancia de SQL Server y una aplicación cliente. TLS usa un certificado para implementar el cifrado.
Al habilitar el cifrado TLS aumenta la seguridad de los datos que se transmiten a través de redes entre instancias de SQL Server y las aplicaciones. Sin embargo, cuando todo el tráfico entre SQL Server y una aplicación cliente se cifra mediante TLS, se requiere el siguiente procesamiento adicional:
- Se requiere un ciclo adicional de ida y vuelta de red en el momento de la conexión.
- La pila TLS del cliente debe cifrar los paquetes enviados desde la aplicación a la instancia de SQL Server y descifrarlos mediante la pila TLS del servidor.
- Los paquetes enviados desde la instancia de SQL Server a la aplicación deben estar cifrados por la pila TLS del servidor y descifrados por la pila TLS del cliente.
Importante
A partir de SQL Server 2016 (13.x), se ha interrumpido la capa de sockets seguros (SSL). En su lugar, use TLS (se recomienda TLS 1.2). Para más información, consulte KB3135244: compatibilidad con TLS 1.2 para Microsoft SQL Server. SQL Server 2022 presenta compatibilidad con TLS 1.3. Para más información, consulte Soporte técnico de TLS 1.3. Si no existen protocolos coincidentes entre el equipo cliente y servidor, puede encontrarse con el error descrito en Una conexión existente fue cerrada forzadamente por el host remoto.
Introducción al certificado digital
Los certificados digitales son archivos electrónicos que funcionan como una contraseña en línea para comprobar la identidad de un usuario o un equipo. Se usan para crear el canal cifrado que se usa para las comunicaciones de cliente. Un certificado es una declaración digital emitida por una entidad de certificación (CA) que representa la identidad del titular del certificado y permite a las partes comunicarse de forma segura mediante el cifrado.
Los certificados digitales proporcionan los siguientes servicios:
- Cifrado: ayudan a proteger los datos que se intercambian contra robos o alteraciones.
- Autenticación: comprueban que sus titulares (personas, sitios web e incluso dispositivos de red como enrutadores) son realmente quién o lo que afirman ser. Normalmente, la autenticación es unidireccional, donde el origen comprueba la identidad del destino, pero también es posible la autenticación tls mutua.
Un certificado contiene una clave pública y adjunta esa clave pública a la identidad de una persona, equipo o servicio que contiene la clave privada correspondiente. El cliente y el servidor usan las claves públicas y privadas para cifrar los datos antes de transmitirlos. Para los usuarios, equipos y servicios de Windows, se establece la confianza en la autoridad de certificación cuando el certificado raíz se define en el almacén de certificados raíz de confianza y el certificado contiene una cadena de certificación válida. Un certificado se considera válido si no se ha revocado (no está en la lista de revocación de certificados, o CRL, de la Autoridad de Certificación) ni ha expirado.
Los tres tipos principales de certificados digitales se describen en la tabla siguiente:
| Tipo | Descripción | Ventajas | Desventajas |
|---|---|---|---|
| Certificado autofirmado | El certificado está firmado por la aplicación que la creó o se crea mediante New-SelfSignedCertificate. | Costo (gratis) | - Los equipos cliente y los dispositivos móviles no confían automáticamente en el certificado. El certificado debe agregarse manualmente al almacén de certificados raíz de confianza en todos los equipos cliente y dispositivos, pero no todos los dispositivos móviles permiten cambios en el almacén de certificados raíz de confianza. - No todos los servicios funcionan con certificados autofirmados. - Difícil de establecer una infraestructura para la administración del ciclo de vida de los certificados. Por ejemplo, los certificados autofirmados no se pueden revocar. |
| Certificado emitido por una entidad de certificación interna | El certificado lo emite una infraestructura de clave pública (PKI) en su organización. Un ejemplo es Servicios de certificados de Active Directory (AD CS). Para obtener más información, consulte Introducción a Los servicios de certificados de Active Directory. | - Permite a las organizaciones emitir sus propios certificados. - Menos caro que los certificados de una entidad de certificación comercial. |
- Mayor complejidad para implementar y mantener la PKI. - Los equipos cliente y los dispositivos móviles no confían automáticamente en el certificado. El certificado debe agregarse manualmente al almacén de certificados raíz de confianza en todos los equipos cliente y dispositivos, pero no todos los dispositivos móviles permiten cambios en el almacén de certificados raíz de confianza. |
| Certificado emitido por una ENTIDAD de certificación comercial | El certificado se adquiere desde una CA comercial de confianza. | La implementación de certificados se simplifica porque todos los clientes, dispositivos y servidores confían automáticamente en los certificados. | El costo. Debe planear con antelación para minimizar el número de certificados necesarios. |
Para demostrar que un titular del certificado es quien dice ser, el certificado debe identificar con precisión el titular del certificado a otros clientes, dispositivos o servidores. Los tres métodos básicos para hacerlo se describen en la tabla siguiente:
| Método | Descripción | Ventajas | Desventajas |
|---|---|---|---|
| Coincidencia del firmante del certificado | El campo Asunto del certificado contiene el nombre común (CN) del host. Por ejemplo, el certificado emitido para www.contoso.com se puede usar para el sitio https://www.contoso.comweb . |
- Compatible con todos los clientes, dispositivos y servicios. -Compartimentación. Revocar el certificado de un host no afecta a otros hosts. |
- Número de certificados necesarios. Solo puede usar el certificado para el host especificado. Por ejemplo, no puede usar el www.contoso.com certificado para ftp.contoso.com, incluso cuando los servicios están instalados en el mismo servidor.-Complejidad. En un servidor web, cada certificado requiere su propio enlace de direcciones IP. |
| Coincidencia del nombre alternativo del firmante (SAN) del certificado | Además del campo Asunto , el campo Nombre alternativo del firmante del certificado contiene una lista de varios nombres de host. Por ejemplo:www.contoso.comftp.contoso.comftp.eu.fabrikam.net |
-Conveniencia. Puede usar el mismo certificado para varios hosts en varios dominios independientes. - La mayoría de los clientes, dispositivos y servicios admiten certificados SAN. - Auditoría y seguridad. Sabe exactamente qué hosts son capaces de usar el certificado SAN. |
- Se requiere más planificación. Debe proporcionar la lista de hosts al crear el certificado. - Falta de compartimentación. No puede revocar de forma selectiva certificados para algunos de los hosts especificados sin afectar a todos los hosts del certificado. |
| Coincidencia de certificado comodín | El campo Asunto del certificado contiene el nombre común como carácter comodín (*) más un único dominio o subdominio. Por ejemplo, *.contoso.com o *.eu.contoso.com. El *.contoso.com certificado comodín se puede usar para:www.contoso.comftp.contoso.commail.contoso.com |
Flexibilidad. No es necesario proporcionar una lista de hosts al solicitar el certificado y puede usar el certificado en cualquier número de hosts que pueda necesitar en el futuro. | - No se pueden usar certificados comodín con otros dominios de nivel superior (TLD). Por ejemplo, no se puede usar el certificado comodín *.contoso.com para hosts *.contoso.net.- Solo puede usar certificados comodín para los nombres de host en el nivel del comodín. Por ejemplo, no puede usar el *.contoso.com certificado para www.eu.contoso.com. O no puede usar el certificado *.eu.contoso.com para www.uk.eu.contoso.com.- Es posible que los clientes, dispositivos, aplicaciones o servicios más antiguos no admitan certificados comodín. - Los comodines no están disponibles con certificados de validación extendida. - Se requieren auditorías cuidadosas y control. Si el certificado comodín está en peligro, afecta a todos los hosts del dominio especificado. |