MSDN Library
Collapse the table of content
Expand the table of content

Capítulo 4 - Comunicación segura

Publicado: 26 de junio de 2006

J.D. Meier, Alex Mackman, Michael Dunner y Srinath Vasireddy
Microsoft Corporation
Octubre de 2002

Consulte la Página de entrada como punto de partida y para obtener una descripción completa del documento Crear aplicaciones ASP.NET seguras.

Resumen: Este capítulo presenta las dos tecnologías básicas que pueden utilizarse para mantener la confidencialidad y la integridad de mensajes para los datos que se transmiten en la red entre clientes y servidores por Internet e intranets corporativas. Se trata de SSL e IPSec. También se explica el cifrado RPC, que puede utilizarse para proteger la comunicación con componentes revisados remotos.

Muchas aplicaciones transmiten datos confidenciales en la red desde los usuarios y a los usuarios y entre nodos de aplicaciones intermedios. Entre los datos confidenciales, pueden figurar credenciales utilizadas para la autenticación o datos como números de tarjeta de crédito o detalles de transacciones bancarias. Para evitar la revelación indeseada de información y proteger los datos contra modificaciones no autorizadas durante la transmisión, deberá protegerse el canal entre los extremos de comunicación.

La comunicación segura ofrece las dos características siguientes:

  • Privacidad. La privacidad se ocupa de garantizar que los datos permanezcan privados y confidenciales y no puedan verlos intrusos que utilicen software de supervisión de redes. La privacidad suele proporcionarse mediante el cifrado.

  • Integridad. Los canales de comunicación segura también deben garantizar que los datos estén protegidos contra modificaciones accidentales o deliberadas (malintencionadas) durante la transmisión. La integridad suele proporcionarse mediante códigos de autenticación de mensajes (MAC, Message Authentication Codes).

Este capítulo trata las siguientes tecnologías de comunicación segura:

  • SSL/TLS (Secure Sockets Layer/Transport Layer Security). Suele utilizarse para proteger el canal entre un explorador y el servidor Web. No obstante, también puede utilizarse para proteger mensajes de servicios Web y comunicaciones con un servidor de bases de datos que ejecute Microsoft® SQL Server™ 2000.

  • Seguridad del protocolo Internet (IPSec). IPSec ofrece una solución para la comunicación segura en el nivel de transporte y puede utilizarse para proteger los datos enviados entre dos equipos, como por ejemplo, entre un servidor de aplicaciones y un servidor de bases de datos.

  • Cifrado de llamada a procedimiento remoto (RPC). El protocolo RPC utilizado por COM distribuido (DCOM) proporciona un nivel de autenticación (privacidad de paquete) que realiza el cifrado de todos los paquetes de datos enviados entre el cliente y el servidor.

Saber lo que se debe proteger

Cuando una petición Web se transmite por los niveles de implementación físicos de la aplicación, cruza varios canales de comunicación. La ilustración 4.1 muestra un modelo de implementación de aplicaciones Web utilizado a menudo.

imagen

Ilustración 4.1
Un modelo típico de implementación Web

En este modelo de implementación, una solicitud pasa por tres canales distintos. El vínculo del cliente al servidor Web puede estar en Internet o en la intranet corporativa y suele utilizar HTTP. Los dos vínculos restantes se realizan entre servidores internos del dominio corporativo. No obstante, los tres vínculos acarrean posibles problemas de seguridad. Muchas aplicaciones basadas exclusivamente en intranet transmiten datos confidenciales de un nivel a otro, como por ejemplo, las aplicaciones de RR.HH. y de nóminas que procesan datos confidenciales de empleados.

La ilustración 4.2 muestra cómo se puede proteger cada canal mediante una combinación de SSL, IPSec y cifrado RPC.

imagen

Ilustración 4.2
Un modelo típico de implementación Web, con comunicaciones seguras

La tecnología elegida depende de varios factores tales como el protocolo de transporte, las tecnologías empleadas por los equipos en los extremos del canal de comunicación y las consideraciones del entorno (como el hardware, las versiones del sistema operativo, los servidores de seguridad, etc.).

En esta página

SSL/TLS SSL/TLS
IPSec IPSec
Cifrado RPC Cifrado RPC
Seguridad punto a punto Seguridad punto a punto
Elegir entre IPSec y SSL Elegir entre IPSec y SSL
Conjuntos y equilibrio de carga Conjuntos y equilibrio de carga
Conclusión Conclusión

SSL/TLS

SSL/TLS sirve para establecer un canal de comunicación cifrada entre el cliente y el servidor. El mecanismo de protocolo de enlace utilizado para establecer el canal seguro está bien documentado y se puede obtener más información en los siguientes artículos de Microsoft Knowledge Base:

  • Q257591, "Description of the Secure Sockets Layer (SSL) Handshake" (en inglés)

  • Q257587, "Description of the Server Authentication Process During the SSL Handshake" (en inglés)

  • Q257586, "Description of the Client Authentication Process During the SSL Handshake" (en inglés)

Utilizar SSL

Al utilizar SSL, deberá tener en cuenta lo siguiente:

  • Cuando se aplica SSL, el cliente utiliza el protocolo HTTPS (y especifica una dirección URL https://) y el servidor escucha en el puerto TCP 443.

  • Deberá supervisar el rendimiento de la aplicación al habilitar SSL.

SSL utiliza funciones criptográficas complejas para cifrar y descifrar datos y, por lo tanto, afecta al rendimiento de la aplicación. La mayor disminución del rendimiento se produce durante el protocolo de enlace inicial, en el que se utiliza cifrado de claves públicas y privadas. Posteriormente (una vez generada e intercambiada una clave de sesión segura), se utiliza cifrado simétrico más rápido para cifrar los datos de la aplicación.

  • Deberá optimizar las páginas que utilizan SSL; para ello, incluya menos texto y use gráficos más sencillos en las páginas.

  • Puesto que el aumento del rendimiento asociado a SSL es mayor durante el establecimiento de la sesión, deberá asegurarse de que no se agote el tiempo de espera de las conexiones.

Para optimizarlo, aumente el valor de la entrada de registro ServerCacheTime. Para obtener más información, consulte el artículo Q247658, "HOW TO: Configure Secure Sockets Layer Server and Client Cache Elements" (en inglés) en Microsoft Knowledge Base.

  • SSL requiere que se haya instalado un certificado de autenticación de servidor en el servidor Web (o en el servidor de bases de datos si utiliza SSL para comunicarse con SQL Server 2000). Para obtener más información acerca de cómo instalar certificados de autenticación de servidor, consulte " Cómo configurar SSL en un servidor Web" en la sección Referencia de esta guía.

IPSec

IPSec puede utilizarse para proteger los datos enviados entre dos equipos, como por ejemplo, un servidor de aplicaciones y un servidor de bases de datos. IPSec es totalmente transparente para las aplicaciones al implementarse los servicios de cifrado, integridad y autenticación en el nivel de transporte. Las aplicaciones siguen comunicándose entre sí de la forma habitual mediante puertos TCP y UDP.

IPSec le permite:

  • Proporcionar confidencialidad de mensajes al cifrar todos los datos enviados entre dos equipos.

  • Proporcionar integridad de mensajes entre dos equipos (sin cifrado de datos).

  • Proporcionar autenticación mutua entre dos equipos (no usuarios). Por ejemplo, puede ayudar a proteger un servidor de bases de datos si establece una directiva que admite peticiones solamente de un equipo cliente específico (por ejemplo, un servidor Web o de aplicaciones).

  • Restringir los equipos que pueden comunicarse entre sí. También puede limitar la comunicación a protocolos IP y puertos TCP/UDP específicos.

Nota

IPSec no reemplaza la seguridad de aplicaciones. Hoy en día, se utiliza como mecanismo defensivo avanzado o para proteger aplicaciones inseguras sin modificarlas, y para proteger protocolos no TLS de ataques de red.

Utilizar IPSec

Al utilizar IPSec, deberá tener en cuenta lo siguiente:

  • IPSec puede utilizarse tanto para la autenticación como para el cifrado.

  • Los desarrolladores no disponen de API de IPSec para controlar la configuración mediante programación. Toda la supervisión y configuración de IPSec se realiza en el complemento IPSec, mediante la directiva de seguridad local de Microsoft Management Console (MMC).

  • IPSec no puede proteger todos los tipos de tráfico IP en el sistema operativo Microsoft Windows® 2000.

En concreto, no se puede utilizar para proteger el tráfico de difusión, multidifusión, intercambio de claves de Internet o Kerberos (que ya es de por sí un protocolo seguro).

Para obtener más información, consulte el artículo Q253169, "Traffic That Can and Cannot Be Secured by IPSec" (en inglés), en Microsoft Knowledge Base.

  • Los filtros IPSec sirven para controlar cuándo se aplica IPSec.

Para probar las directivas IPSec, utilice el Monitor de IPSec. El Monitor de IPSec (Ipsecmon.exe) proporciona información acerca de qué directiva IPSec está activa y de si se ha establecido un canal seguro entre equipos.

Para obtener más información, consulte los artículos de Knowledge Base:

  • Q313195, "HOW TO: Use IPSec Monitor in Windows 2000" (en inglés)

  • Q231587, "Using the IP Security Monitor Tool to View IPSec Communications" (en inglés)

Para establecer una confianza entre dos servidores, puede utilizar IPSec con autenticación mutua. Ésta utiliza certificados para autenticar ambos equipos.

Para obtener más información, consulte los siguientes artículos de Knowledge Base:

  • Q248711, "Mutual Authentication Methods Supported for L2TP/IPSec" (en inglés)

  • Q253498, "HOW TO: Install a Certificate for Use with IP Security" (en inglés)

Si necesita utilizar IPSec para proteger la comunicación entre dos equipos que están separados por un servidor de seguridad, asegúrese de que el servidor de seguridad no utiliza la Traducción de direcciones de red (NAT, Network Address Translation). IPSec no funciona con ningún dispositivo basado en NAT.

Para obtener más información y pasos de configuración, consulte el artículo Q233256, "HOW TO Enable IPSec Traffic through a Firewall" (en inglés), en Microsoft Knowledge Base y "Cómo: Utilizar IPSec para proporcionar comunicación segura entre dos servidores" en la sección Referencia de esta guía.

Cifrado RPC

RPC es el mecanismo de transporte subyacente utilizado por DCOM. RPC ofrece un conjunto de niveles de autenticación configurables, desde ninguna autenticación (y ninguna protección de los datos) al cifrado total del estado de los parámetros.

El nivel más seguro (Privacidad de paquete RPC) cifra el estado de los parámetros para cada llamada a procedimiento remoto (y, por lo tanto, todas las invocaciones de métodos DCOM). El nivel de cifrado RPC (40 bits o 128 bits) depende de la versión del sistema operativo Windows que se ejecuta en los equipos cliente y servidor.

Utilizar el cifrado RPC

Es más probable que desee utilizar el cifrado RPC cuando la aplicación Web se comunica con componentes revisados (en aplicaciones de servidor de Servicios Empresariales) que se encuentran ubicados en equipos remotos.

En este caso, deberá configurar tanto el cliente como el servidor para que utilicen la autenticación de Privacidad de paquete RPC (y el cifrado). Se produce un proceso de negociación de límites entre el cliente y el servidor, lo que garantiza que se utiliza la configuración del que posee el nivel de seguridad más alto (cliente y servidor).

La configuración del servidor puede definirse en la aplicación (Servicios Empresariales), tanto mediante atributos de .NET en el ensamblado de componentes revisados como mediante la herramienta de administración Servicios de componente durante la implementación.

Si el cliente es una aplicación Web ASP.NET o un servicio Web, el nivel de autenticación utilizado por el cliente se configura mediante el atributo comAuthenticationLevel en el elemento de Machine.config. Así se proporciona el nivel de autenticación predeterminado para todas las aplicaciones ASP.NET que se ejecutan en el servidor Web.

Más información

Para obtener más información acerca de la negociación del nivel de autenticación RPC y la configuración de componentes de servicio, consulte el capítulo 9, "Seguridad de la aplicación de Servicios Empresariales".

Seguridad punto a punto

Los escenarios de comunicación punto a punto pueden clasificarse en los siguientes temas:

  • Explorador y servidor Web

  • Servidor Web y servidor de aplicaciones remoto

  • Servidor de aplicaciones y servidor de bases de datos

Explorador y servidor Web

Para proteger datos confidenciales enviados entre un explorador y un servidor Web, deberá utilizar SSL. Necesitará utilizar SSL en las siguientes situaciones:

  • Utiliza la autenticación mediante Formularios y necesita proteger las credenciales de texto no cifrado enviadas a un servidor Web desde un formulario de inicio de sesión.

En este escenario, deberá utilizar SSL para proteger el acceso a todas las páginas (y no sólo la página de inicio de sesión) con el fin de garantizar que la cookie de autenticación que se genera a partir del proceso de autenticación inicial permanezca segura durante toda la duración de la sesión de explorador del cliente con la aplicación.

  • Utiliza la autenticación básica y necesita proteger las credenciales de texto no cifrado (codificación Base64).

Deberá utilizar SSL para proteger el acceso a todas las páginas (y no sólo la página de inicio de sesión), puesto que la autenticación básica envía las credenciales de texto no cifrado al servidor Web con todas las peticiones de la aplicación (y no sólo la inicial).

Nota

Base64 sirve para codificar datos binarios como texto ASCII imprimible. A diferencia del cifrado, no proporciona privacidad ni integridad de mensajes.

  • Su aplicación transmite datos confidenciales del explorador al servidor Web (y viceversa), como por ejemplo, números de tarjeta de crédito o información de cuentas bancarias.

Servidor Web y servidor de aplicaciones remoto

El canal de transporte entre un servidor Web y un servidor de aplicaciones remoto deberá protegerse con IPSec, SSL o cifrado RPC. La elección depende de los protocolos de transporte y factores del entorno (versiones del sistema operativo, servidores de seguridad, etc.).

  • Servicios Empresariales. Si el servidor remoto aloja uno o varios componentes revisados (en una aplicación de servidor de Servicios Empresariales) y se comunica directamente con ellos (y, por lo tanto, utiliza DCOM), deberá usar el cifrado de Privacidad de paquete RPC.

Para obtener más información acerca de cómo configurar el cifrado RPC entre una aplicación Web y un componente revisado remoto, consulte el capítulo 9, "Seguridad de la aplicación de Servicios Empresariales".

  • Servicios Web. Si el servidor remoto aloja un servicio Web, puede elegir entre IPSec y SSL.

En general, deberá utilizar SSL porque el servicio Web ya utiliza el transporte HTTP. SSL también le permite cifrar solamente los datos enviados al servicio Web y desde el servicio Web (y no todo el tráfico entre los dos equipos). IPSec realiza el cifrado de todo el tráfico entre los dos equipos.

Nota

La iniciativa Arquitectura global de servicios Web XML (GXA) y, en concreto, la especificación WS-Security se ocupan de la seguridad de mensajes (incluido el cifrado de datos). Microsoft proporciona el Kit de desarrollo de Servicios Web para que pueda desarrollar soluciones de seguridad de mensajes.

Componentes de .NET (mediante .NET Remoting). Si el servidor remoto aloja uno o varios componentes de .NET y se conecta a ellos mediante el canal TCP, puede utilizar IPSec para proporcionar un vínculo de comunicación segura. Si aloja los componentes de .NET en ASP.NET, puede utilizar SSL (configurado mediante IIS).

Servidor de aplicaciones y servidor de bases de datos

Para proteger los datos enviados entre un servidor de aplicaciones y un servidor de bases de datos, puede utilizar IPSec. Si el servidor de bases de datos ejecuta SQL Server 2000 (y las bibliotecas de red de SQL Server 2000 están instaladas en el servidor de aplicaciones), puede utilizar SSL. Esta última opción requiere que esté instalado un certificado de autenticación de servidor en el almacén del equipo del servidor de bases de datos.

Es posible que necesite proteger el vínculo al servidor de bases de datos en las siguientes situaciones:

  • Se conecta al servidor de bases de datos y no utiliza la autenticación de Windows. Por ejemplo, utiliza la autenticación de SQL para SQL Server o se conecta a una base de datos que no es de SQL Server. En estos casos, las credenciales se transmiten como texto no cifrado, lo que puede acarrear un problema de seguridad considerable.

Nota

Una de las ventajas clave del uso de la autenticación de Windows para SQL Server reside en que las credenciales nunca se transmiten por la red. Para obtener más información acerca de la autenticación de Windows y SQL, consulte el capítulo 12, " Seguridad del acceso a datos".

  • Su aplicación envía datos confidenciales a la base de datos y también recupera datos confidenciales de la base de datos (por ejemplo, información de nóminas).

Utilizar SSL para SQL Server

Considere los siguientes aspectos si utiliza SSL para proteger el canal a una base de datos de SQL Server:

  • Para que funcione SSL, debe instalar un certificado de autenticación de servidor en el almacén del equipo servidor de bases de datos. El equipo cliente deberá tener además un certificado de entidad emisora raíz de la misma entidad que emitió el certificado de servidor (o una entidad de confianza).

  • Los clientes deben tener instaladas las bibliotecas de conectividad de SQL Server 2000. Las versiones anteriores de bibliotecas genéricas no son válidas en este caso.

  • SSL sólo funciona con TCP/IP (el protocolo de comunicación recomendado para SQL Server) y las canalizaciones con nombre. • Puede configurar el servidor de forma que exija el uso de cifrado para todas las conexiones (de todos los clientes).

En el cliente, puede:

  • Exigir el uso de cifrado para todas las conexiones salientes.

  • Permitir que las aplicaciones cliente puedan elegir si utilizan o no el cifrado en cada conexión mediante la cadena de conexión.

  • A diferencia de IPSec, en SSL los cambios de configuración no son necesarios si se modifican las direcciones IP del cliente o del servidor.

Más información

Para obtener más información acerca de cómo utilizar SSL para SQL Server, consulte los siguientes recursos:

Elegir entre IPSec y SSL

Considere los siguientes aspectos a la hora de elegir entre IPSec y SSL:

  • IPSec puede utilizarse para proteger todo el tráfico IP entre equipos; SSL es específico de una aplicación concreta.

  • IPSec es una configuración general del equipo y no admite el cifrado de conexiones de red específicas. No obstante, los sitios pueden dividirse para utilizar o no utilizar SSL. Además, cuando se utiliza SSL para establecer la conexión con SQL Server, puede elegir si desea utilizar o no SSL en cada conexión (desde la aplicación cliente).

  • IPSec es transparente para las aplicaciones y, por lo tanto, puede utilizarse con protocolos seguros que se ejecutan sobre IP, como HTTP, FTP y SMTP. Por el contrario, SSL/TLS está vinculado estrechamente a la aplicación.

  • IPSec, además de para el cifrado, también puede utilizarse para la autenticación de equipos. Resulta especialmente importante para los escenarios de subsistemas de confianza, en los que la base de datos autoriza a una identidad fija desde una aplicación específica (que se ejecuta en un equipo determinado). IPSec puede utilizarse para garantizar que sólo el servidor de aplicaciones específico pueda conectarse al servidor de bases de datos, con el fin de evitar ataques desde otros equipos.

  • IPSec requiere que ambos equipos ejecuten Windows 2000 o posterior.

  • SSL puede funcionar a través de un servidor de seguridad basado en NAT e IPSec no.

Conjuntos y equilibrio de carga

Si utiliza SSL conjuntamente con varios sitios Web virtuales, necesitará utilizar direcciones IP o números de puerto únicos. No se pueden utilizar varios sitios con la misma dirección IP y número de puerto. Si se combina la dirección IP con una configuración de afinidad del servidor en un equilibrador de carga, sí que se puede utilizar este método.

Más información

Para obtener más información, consulte el artículo Q187504, "HTTP 1.1 Host Headers Are Not Supported When You Use SSL" (en inglés), en Microsoft Knowledge Base.

Conclusión

Este capítulo describió cómo se puede utilizar una combinación de SSL, IPSec y cifrado RPC para ofrecer una comunicación segura de extremo a extremo para la aplicación distribuida. Para resumir:

  • La seguridad de canales constituye un problema para los datos transmitidos en Internet y en la intranet corporativa.

  • Considere los requisitos de seguridad de los vínculos del explorador Web al servidor Web, del servidor Web al servidor de aplicaciones y del servidor de aplicaciones al servidor de bases de datos.

  • La comunicación segura proporciona privacidad e integridad. No ofrece protección contra el no rechazo (para esto deberá utilizar certificados de cliente).

  • Las opciones de seguridad de canales son SSL, IPSec y el cifrado RPC. La última opción se utiliza cuando la aplicación utiliza DCOM para comunicarse con componentes revisados remotos.

  • Si utiliza SSL para comunicarse con SQL Server, la aplicación puede elegir (en cada conexión) si cifra o no la conexión.

  • IPSec cifra todo el tráfico IP que se transmite entre dos equipos.

  • La elección del mecanismo de seguridad depende del protocolo de transporte, las versiones del sistema operativo y las consideraciones de red (incluidos los servidores de seguridad).

  • La comunicación segura y el rendimiento siempre van en detrimento el uno del otro. Elija el nivel de seguridad que sea adecuado para los requisitos de la aplicación.

Mostrar:
© 2016 Microsoft