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 del protocolo de aplicación y la capa TCP/IP, donde pueden proteger y enviar datos de la aplicación a la capa de transporte. Los protocolos TLS/SSL usan algoritmos de un conjunto de cifrado para crear claves y cifrar la 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 de conexión inicial (antes del inicio de sesión) 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 los protocolos TLS compatibles con las diferentes versiones de los sistemas operativos Windows, consulte Protocolos de 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. Pero cuando todo el tráfico entre SQL Server y una aplicación cliente se cifra mediante TLS, es necesario el procesamiento adicional siguiente:
- Se requiere un ciclo adicional de ida y vuelta de red en el momento de la conexión.
- Los paquetes enviados desde la aplicación a la instancia de SQL Server los debe cifrar la pila TLS de cliente y los debe descifrar la pila TLS de servidor.
- Los paquetes enviados desde la aplicación a la instancia de SQL Server los debe cifrar la pila TLS de servidor y los debe descifrar la pila TLS de cliente.
Importante
A partir de SQL Server 2016 (13.x), ya no se incluye Capa de sockets seguros (SSL). Use en su lugar 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 ofrece 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 producirse el error que se describe en El host remoto forzó el cierre de una conexión existente.
Información general sobre los certificados digitales
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, a su vez, se usa para las comunicaciones del cliente. Un certificado es un documento digital emitido por una entidad de certificación (CA) que garantiza la identidad del titular del certificado y permite a las partes implicadas comunicarse de forma segura mediante el cifrado.
Los certificados digitales proporcionan los servicios siguientes:
- Cifrado: ayudan a proteger los datos que se intercambian contra robos o alteraciones.
- Autenticación: verifican que sus titulares (personas, sitios web o incluso dispositivos de red, como enrutadores) son realmente quienes dicen ser. Normalmente, la autenticación es unidireccional (es decir, 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 asocia esa clave pública a la identidad de una persona, equipo o servicio que posea la clave privada correspondiente. El cliente y el servidor usan las claves públicas y privadas para cifrar los datos antes de que se transmitan. Para los usuarios, equipos y servicios de Windows, la confianza en una CA se establece cuando el certificado raíz está definido en el almacén de certificados raíz de confianza y contiene una ruta de acceso 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 entidad de certificación) o no ha expirado.
En la tabla siguiente se describen los tres tipos principales de certificados digitales:
| Tipo | Descripción | Ventajas | Inconvenientes |
|---|---|---|---|
| Certificado autofirmado | El certificado está firmado por la aplicación que lo creó o se ha creado mediante New-SelfSignedCertificate. | Coste (gratuito). | - Los equipos cliente y 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 y dispositivos cliente, pero no todos los dispositivos móviles permiten los cambios en el almacén de certificados raíz de confianza. - No todos los servicios funcionan con certificados autofirmados. - Es difícil 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) de la organización. Por ejemplo, los 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 que las organizaciones emitan sus propios certificados. - Es menos costoso que los certificados de una entidad de certificación comercial. |
- Existe una mayor complejidad para implementar y mantener la PKI. - Los equipos cliente y 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 y dispositivos cliente, pero no todos los dispositivos móviles permiten los cambios en el almacén de certificados raíz de confianza. |
| Certificado emitido por una entidad de certificación comercial | El certificado se compra a través de 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 en otros clientes, dispositivos o servidores. Los tres métodos básicos para hacerlo se describen en la tabla siguiente:
| Método | Descripción | Ventajas | Inconvenientes |
|---|---|---|---|
| Coincidencia del firmante del certificado | El campo Firmante del certificado contiene el nombre común del host. Por ejemplo, el certificado que se emite para www.contoso.com se puede usar para el sitio web https://www.contoso.com. |
- Compatible con todos los clientes, dispositivos y servicios. - Compartimentación. Si se revoca el certificado de un host, no afecta a otros hosts. |
- Número de certificados necesarios. Solo se puede usar el certificado para el host especificado. Por ejemplo, no puede usar el certificado www.contoso.com 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 Firmante, el campo Nombre alternativo del firmante del certificado contiene una lista de nombres de host. Por ejemplo:www.contoso.comftp.contoso.comftp.eu.fabirkam.net |
- Comodidad. 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 se pueden 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 Firmante 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 certificado comodín *.contoso.com 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 necesite 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 certificado *.contoso.com para www.eu.contoso.com. Tampoco puede usar el certificado *.eu.contoso.com para www.uk.eu.contoso.com.- Es posible que 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 y controles cuidadosos. Si el certificado comodín está en peligro, afecta a todos los hosts del dominio especificado. |