Descripción de la seguridad de la mensajería unificada VoIP
Se aplica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3
Última modificación del tema: 2016-11-28
Un aspecto importante de la seguridad de la red es la posibilidad de proteger la infraestructura de la mensajería unificada. Hay componentes en el entorno de mensajería unificada que deben configurarse correctamente para ayudar a proteger los datos que se envían y reciben en los servidores de mensajería unificada de la red. Entre ellos se encuentran componentes como los servidores de mensajería unificada y los planes de marcado. En este tema se trata cómo aumentar la protección de los datos y servidores de red de mensajería unificada de la organización. Debe seguir estos pasos para ayudar a proteger el entorno de Mensajería unificada y habilitar la seguridad de VoIP (voz a través de IP):
Instale el rol del servidor Mensajería unificada.
Cree un nuevo certificado público o autofirmado que pueda usar para la TLS mutua.
Asocie un certificado con el servidor de mensajería unificada.
Configure el plan de marcado de mensajería unificada como protegido con SIP o Protegido.
Configure el modo de inicio en el servidor de mensajería unificada.
Asocie los servidores de mensajería unificada al plan de marcado de mensajería unificada.
Configure las puertas de enlace IP de mensajería unificada que sirven para tener un nombre de dominio completo (FQDN) y para usar el puerto TCP 5061.
Exporte e importe los certificados necesarios para que los servidores de mensajería unificada, puertas de enlace IP, centrales de conmutación IP (IP PBX) y demás servidores que ejecutan MicrosoftExchange Server 2010 puedan usar la Seguridad de la capa de transporte mutua (TLS mutua).
Contenido
Protección de la mensajería unificada
Tipos de certificados
Configuración de la TLS mutua
IPsec
Planes de marcado de mensajería unificada y seguridad de VoIP
Modo en que la mensajería unificada determina la seguridad y selecciona los certificados
Protección de la mensajería unificada
Existen varios métodos de seguridad que pueden servir para proteger los servidores de mensajería unificada y el tráfico de red que se envía entre las puertas de enlace IP y los servidores de mensajería unificada, así como entre los servidores de mensajería unificada y otros servidores de Exchange 2010 de la organización. En la siguiente tabla se muestran algunas de las posibles amenazas a la infraestructura de mensajería unificada y los métodos de seguridad que se pueden implementar para protegerla.
Protección de la mensajería unificada
| ¿Contra qué me estoy protegiendo? | ¿Cómo me puedo proteger? |
|---|---|
Supervisión del tráfico de voz |
|
Un ataque contra una puerta de enlace IP o IP PBX |
|
Llamadas de larga distancia no autorizadas |
|
Un ataque de denegación de servicio |
|
Usurpación de identidad del proxy de Protocolo de inicio de sesión (SIP) |
|
Escuchas no autorizadas y secuestros de sesión |
|
En la tabla anterior se detallan varios métodos de seguridad que puede usar para proteger su entorno de Mensajería unificada. Uno de los mecanismos más importantes para proteger la infraestructura de mensajería unificada y el tráfico de red que ésta genera es la TLS mutua.
La TLS mutua se puede usar para cifrar el tráfico de VoIP (voz a través de IP) que pasa entre puertas de enlace IP, IP PBX y otros servidores de Exchange 2010 y los servidores de mensajería unificada de la red. La mejor opción para proteger estos datos consiste en usar la TLS mutua para cifrar los datos de VoIP.
No obstante, en función de la amenaza a la seguridad, también puede configurar directivas de IPsec para habilitar el cifrado entre puertas de enlace IP o IP PBX y un servidor de mensajería unificada, o entre un servidor de mensajería unificada y otros servidores de Exchange 2010 de la red. En algunos entornos, es posible que no pueda usar IPsec porque no esté disponible o no se admita en las puertas de enlace IP o IP PBX. Asimismo, IPsec supone una carga adicional de procesamiento para los recursos del sistema de los servidores de mensajería unificada. Teniendo en cuenta estos dos factores, la TLS mutua es una opción mejor para proteger el tráfico de red de VoIP en el entorno de mensajería unificada.
Una vez que haya implementado y configurado correctamente la TLS mutua, el tráfico de VoIP entre las puertas de enlace IP, las IP PBX y el procedente de otros servidores de Exchange a los servidores de mensajería unificada estará cifrado. No obstante, se usan otros tipos de cifrados para proteger los datos cuando no se puede usar la TLS mutua para proteger el tráfico que se envía o se recibe en un servidor de mensajería unificada; por ejemplo, cuando un servidor de mensajería unificada se comunica con otro servidor de la red (por ejemplo, un controlador de dominio de Active Directory o un servidor de buzones de correo de Exchange 2010). En la siguiente figura se muestran los métodos de cifrado que se pueden usar para proteger la mensajería unificada.
Seguridad VoiP de mensajería unificada
Volver al principio
Tipos de certificados
Los certificados digitales son archivos electrónicos que funcionan como un pasaporte en línea para comprobar la identidad de un usuario o un equipo y que sirven para crear un canal cifrado que proteja los datos. Un certificado es, básicamente, una declaración digital emitida por una entidad de certificación (CA) que garantiza la identidad del poseedor del certificado y permite que las partes se comuniquen de forma segura mediante el cifrado. La emisión de este tipo de certificados puede correr a cargo de una CA de terceros de confianza, como Servicios de certificados, o bien ser autofirmada. Cada tipo de certificado tiene sus ventajas y desventajas. No obstante, los certificados siempre están protegidos contra manipulaciones y no se pueden falsificar. Se pueden emitir para diversas funciones: autenticación de usuario de web, autenticación de servidor web, S/MIME, IPsec, TLS y firma de códigos.
Un certificado vincula una clave pública con la identidad de la persona, el equipo o el servicio que posee la clave privada correspondiente. Tanto el cliente como el servidor usan las claves públicas y privadas para cifrar los datos antes de transmitirlos a través de la red. Una amplia variedad de servicios y aplicaciones de seguridad de clave pública, que proporcionan autenticación, integridad de datos y comunicaciones seguras en redes, como puede ser Internet, usa certificados. Para usuarios, equipos y servicios basados en Windows, la confianza en una CA se establece cuando hay una copia del certificado raíz en el almacén de certificados raíz de confianza y el certificado contiene una ruta de certificación válida. Esto significa que no se ha revocado ningún certificado en la ruta de acceso de la certificación y que no ha expirado el período de validez de ninguno de los certificados.
Los certificados digitales hacen lo siguiente:
Dan fe de que sus poseedores (personas, sitios web e incluso recursos de red como enrutadores) son de verdad quien dicen ser.
Protegen los datos que se intercambian en línea de posibles robos y alteraciones.
Tradicionalmente hay tres opciones o tipos de certificados que pueden usar la Mensajería unificada y las puertas de enlace IP o IP PBX. En estos tres enfoques u opciones, la clave pública del propietario del certificado es parte del certificado, por lo que el servidor, usuario, sitio web o recurso que está en el otro extremo puede descifrar los mensajes. La clave privada sólo la conoce el que firma el certificado. Cada certificado tiene un atributo EnhancedKeyUsage establecido para dictar el uso específico del mismo. Por ejemplo, se podría especificar que sólo se use para autenticación del servidor o con el sistema de archivos de cifrado. La mensajería unificada usa los certificados para autenticar servidores y cifrar datos.
Certificados autofirmados
Un certificado autofirmado es aquél que firma su propio creador. El asunto y el nombre del certificado son iguales. En los certificados autofirmados, el emisor y el asunto están definidos en el certificado. Los certificados autofirmados no requieren de la presencia de una CA de la organización o de un tercero. Estos certificados se deben configurar de forma explícita y copiarse en el almacén de certificados raíz de confianza de cada puerta de enlace IP, IP PBX, otros servidores de mensajería unificada y demás equipos de Exchange 2010, para que el servidor de mensajería unificada que ha emitido el certificado confíe en ellos.
Si no hay disponible ningún certificado de terceros o basado en infraestructura de clave pública (PKI), el servidor de mensajería unificada buscará un certificado autofirmado en el almacén local de certificados. Si no encuentra un certificado de terceros o de PKI, generará un certificado autofirmado para TLS mutua. No obstante, debido a que es un certificado autofirmado, las puertas de enlace IP, las IP PBX de la red u otros servidores de la red no confiarán en él. Para asegurarse de que esto no suceda, deberá importarlo al almacén local de certificados raíz de confianza de los dispositivos y los servidores. Una vez hecho esto, cuando el servidor de mensajería unificada presente este certificado autofirmado a la puerta de enlace IP, IP PBX o servidor, podrá comprobar que una entidad de confianza ha emitido el certificado, ya que el emisor será igual al asunto definido en el certificado autofirmado.
Si sólo usa certificados autofirmados, deberá importar un único certificado autofirmado para cada puerta de enlace IP, IP PBX o servidor. En entornos de red grandes con varios dispositivos o equipos, puede que ésta no sea la mejor opción para implementar TLS mutua. El uso de certificados autofirmados en redes empresariales grandes no es lo más adecuado, dada la sobrecarga administrativa adicional que supone. Sin embargo, esta sobrecarga administrativa no es un problema si dispone de múltiples dispositivos y usa un certificado comercial de terceros o de PKI. Esto se debe a que cada dispositivo tiene un certificado emitido por la misma autoridad raíz de confianza. Tener un certificado de la misma autoridad raíz de confianza garantiza que todas las puertas de enlace IP, las IP PBX y los otros servidores confíen en el servidor de mensajería unificada.
Para que la TLS mutua funcione con certificados autofirmados:
Importe el certificado autofirmado del servidor de mensajería unificada al almacén de certificados raíz de confianza de cada puerta de enlace IP, IP PBX y otros servidores con los que se comunicará el servidor de mensajería unificada mediante la TLS mutua.
Importe el certificado autofirmado de cada puerta de enlace IP, IP PBX u otros servidores al almacén de certificados raíz de confianza del servidor de mensajería unificada. Si va a usar un certificado de terceros o de PKI, debe importar el certificado de la entidad de certificación al almacén de certificados raíz de confianza de todos los dispositivos y servidores.
En muchos casos los certificados autofirmados no son la mejor opción cuando se desea implementar la autenticación de TLS mutua o basada en certificados. No obstante, las organizaciones más pequeñas con un número reducido de dispositivos o equipos pueden optar por usar el método de certificados autofirmados, por ser el más fácil de configurar y el más barato de usar a la hora de implementar la TLS mutua. Con frecuencia, las organizaciones de menor tamaño deciden no usar un certificado de terceros o instalar su propia PKI para emitir certificados debido al gasto que supone, a la falta de experiencia y conocimientos de sus administradores para crear su propia jerarquía de certificados, o a ambas razones. El uso de certificados autofirmados tiene un costo mínimo y una configuración muy sencilla. Sin embargo, establecer una infraestructura para la administración del ciclo de vida, la renovación, la administración de la confianza y la revocación de los certificados es mucho más difícil con los certificados autofirmados. Para obtener más información acerca de cómo crear un certificado para TLS, consulte Descripción de los certificados TLS.
Volver al principio
Infraestructura de clave pública
Una infraestructura de clave pública (PKI) es un sistema de certificados digitales, entidades de certificación (CA) y entidades de registro (RA), que comprueban y autentican la validez de cada parte implicada en una transacción electrónica mediante el uso de criptografía con claves públicas. Cuando implementa una CA en una organización que usa Active Directory, proporciona una infraestructura para la administración del ciclo de vida, la renovación, la administración de la confianza y la revocación de los certificados. Estas cualidades proporcionan una infraestructura sólida para todos los certificados de la organización. Todo esto, sin embargo, lleva un costo asociado al tener que implementar servidores e infraestructuras adicionales para crear y administrar este tipo de certificados.
Los Servicios de Certificate Server se pueden instalar en cualquier servidor del dominio. Si obtiene certificados de una CA de dominio basada en Windows, puede usarla para solicitar o firmar certificados que emitirá a sus propios servidores o equipos de la red. De este modo, se puede usar una PKI como si se tratara de un proveedor externo de certificados, pero con menor costo. A pesar de que estas PKI no se pueden implementar públicamente, a diferencia de otros tipos de certificados, cuando se usa una PKI, se comprueba el solicitante y una CA firma el certificado del solicitante con la clave privada. La clave pública de esta CA es parte del certificado emitido por la CA. Cualquiera que tenga este certificado de CA como certificado raíz puede usar esa clave pública para autenticar al solicitante y descifrar su certificado.
Cuando usa un certificado de PKI para implementar la TLS mutua, debe copiar los certificados necesarios en las puertas de enlace IP o IP PBX. A continuación, debe copiar los certificados de las puertas de enlace IP o IP PBX en los servidores de mensajería unificada asociados al plan de marcado de mensajería unificada que se ha configurado en modo seguro.
La instalación y la configuración para usar certificados de PKI y certificados de terceros son similares a los procedimientos que se realizan para importar o exportar certificados autofirmados. Sin embargo, no sólo se tiene que instalar el certificado del equipo en el almacén de certificados raíz de confianza. También se debe importar o copiar el certificado de raíz de confianza para PKI en el almacén de certificados de raíz de confianza en los servidores de Mensajería unificada y las puertas de enlace IP e IP PBX en su red.
Para implementar la TLS mutua una vez que haya implementado una infraestructura de PKI, siga estos pasos:
Genere una solicitud de certificado en cada puerta de enlace IP o PBX.
Copie la solicitud de certificado para usarla cuando solicite el certificado a una entidad de certificación.
Solicite un certificado a la entidad de certificación mediante la solicitud correspondiente. Guarde el certificado.
Importe el certificado que ha guardado a cada dispositivo o equipo.
Descargue el certificado raíz de confianza para la PKI.
Importe el certificado raíz de confianza de la PKI a cada dispositivo. Si va a importar el certificado raíz de confianza a un equipo de Exchange 2010 que está ejecutando el rol de servidor Mensajería unificada, también puede usar la directiva de grupo para importarlo al almacén de certificados raíz de confianza del servidor de mensajería unificada u otros servidores de Exchange 2010. Este proceso también se usa, no obstante, al configurar un servidor que está ejecutando el rol del servidor Mensajería unificada.
Nota
Estos mismos pasos son válidos si usa un certificado comercial de terceros para implementar la TLS mutua.
Para obtener más información sobre los certificados y PKI, consulte los siguientes temas:
Para obtener más información acerca de los certificados, consulte Infraestructura de claves públicas para Windows Server 2003 (en inglés).
Para obtener más información acerca de las prácticas recomendadas para implementar una infraestructura de clave pública de Windows Server 2003, consulte Prácticas recomendadas para la implementación de una infraestructura de clave pública de Microsoft Windows Server 2003 (en inglés).
Para obtener más información acerca de cómo implementar una PKI basada en Windows Server 2008, consulte Ejemplo de implementación paso a paso de los certificados de PKI necesarios para usar el modo nativo del Administrador de configuración: entidad de certificación de Windows Server 2008 (en inglés).
Para obtener más información acerca de Servicios de certificados de Windows Server 2008 de una PKI basada en Windows Server 2008, consulte Información general sobre Servicios de certificado de Active Directory (en inglés).
Entidades de certificación externas
Los certificados comerciales o de terceros son certificados generados por una CA externa o comercial, que se han adquirido para usar en los servidores de red. Uno de los problemas de los certificados autofirmados o basados en PKI es que, debido a que el certificado no es de confianza, se debe asegurar de importarlo al almacén de certificados raíz de confianza de los servidores, los dispositivos y los equipos cliente. Los certificados comerciales o de terceros no tienen este problema. La mayoría de los certificados de CA comerciales son de confianza porque el certificado ya reside en el almacén de certificados raíz de confianza. Dado que el emisor es de confianza, el certificado también lo es. El uso de certificados de terceros simplifica notablemente la implementación.
Para las organizaciones de mayor tamaño o las que deben implementar certificados de forma pública, el uso de certificados comerciales o de terceros es la mejor opción, a pesar del costo que lleva asociado. Los certificados comerciales pueden no ser la mejor solución para las organizaciones de pequeño o mediano tamaño, por lo que quizás prefiera usar alguna de las otras opciones de certificados que hay disponibles.
En función de la configuración de la puerta de enlace IP o IP PBX, quizás siga teniendo que importar el certificado comercial o de terceros en el almacén de certificados de confianza de las puertas de enlace IP o IP PBX para poder usarlo para la TLS mutua. No obstante, en algunos casos, el certificado de terceros estará incluido en el almacén de certificados raíz de confianza del servidor de mensajería unificada y otros equipos de Exchange 2010 de su organización.
Los procedimientos que lleva a cabo para usar un certificado comercial o de terceros con el fin de habilitar la TLS mutua son los mismos que cuando usa un certificado de PKI. La única diferencia es que no tendrá que generar un certificado de PKI, ya que habrá obtenido el certificado de un proveedor de certificados comerciales y éste se importará a su almacén de certificados raíz de confianza de los servidores y los dispositivos de la red.
Volver al principio
Configuración de la TLS mutua
De forma predeterminada, cuando se recibe una llamada entrante de una puerta de enlace IP, el tráfico de VoIP no está cifrado ni usa TLS mutua. No obstante, la opción de seguridad de un servidor de mensajería unificada se configura en el plan de marcado de mensajería unificada asociado a dicho servidor. Para que el servidor de mensajería unificada se pueda comunicar de forma segura con puertas de enlace IP, IP PBX y demás servidores de Exchange 2010, debe usar el cmdlet Set-UMDialPlan para configurar la seguridad de VoIP en el plan de marcado de mensajería unificada y, a continuación, habilitar la TLS mutua para los servidores de mensajería unificada que están asociados al plan de marcado de mensajería unificada.
Una vez que haya habilitado la seguridad de VoIP en el plan de marcado de mensajería unificada, todos los servidores de mensajería unificada que están asociados a dicho plan se podrán comunicar de forma segura. No obstante, en función del tipo de certificado que use para habilitar la TLS mutua, primero deberá importar y exportar los certificados necesarios tanto en los servidores de Mensajería unificada como en las puertas de enlace IP y PBX. Una vez que se hayan importado los certificados necesarios al servidor de mensajería unificada, deberá reiniciar el Servicio de mensajería unificada de MicrosoftExchange con el fin de poder usar el certificado que se ha importado y establecer una conexión cifrada con las puertas de enlace IP o IP PBX. Para obtener más información acerca de cómo importar y exportar certificados, consulte Importar y exportar certificados (en inglés).
Una vez que haya importado y exportado correctamente los certificados de confianza necesarios, la puerta de enlace IP solicitará un certificado al servidor de mensajería unificada que, a su vez, solicitará un certificado a la puerta de enlace IP. El intercambio de certificados de confianza entre la puerta de enlace IP y el servidor de mensajería unificada permite que la puerta de enlace IP y dicho servidor se comuniquen a través de una conexión cifrada que usa la TLS mutua. Cuando una puerta de enlace IP o IP PBX recibe una llamada entrante, inicia un intercambio de certificados y negocia la seguridad mediante el uso de la TLS mutua con el servidor de mensajería unificada. El servicio de mensajería unificada de Microsoft Exchange no interviene en el proceso de intercambio de certificados a la hora de determinar si el certificado es válido. Sin embargo, si no se da con ningún certificado de confianza en un servidor de mensajería unificada, si se encuentra un certificado de confianza pero no es válido o si se rechaza la llamada por un error de negociación de la TLS mutua, el servidor de mensajería unificada recibirá una notificación del Servicio de mensajería unificada de Microsoft Exchange.
A pesar de que el Servicio de mensajería unificada de Microsoft Exchange no participa en el intercambio de certificados entre el servidor de mensajería unificada y las puertas de enlace IP, sí realiza las siguientes funciones:
Proporciona una lista de FQDN al servicio Speech de Microsoft Exchange, de forma que solo se aceptan las llamadas de puertas de enlace IP o IP PBX incluidas en la lista.
Transfiere los atributos issuerName y SerialNumber de un certificado al servicio de voz de Microsoft Exchange. Estos atributos identifican de manera exclusiva el certificado que el servidor de mensajería unificada usará si una puerta de enlace IP o IP PBX solicitan un certificado.
Una vez que el servidor de mensajería unificada y las puertas de enlace IP o IP PBX hayan intercambiado las claves para establecer una conexión cifrada mediante el uso de la TLS mutua, los servidores de mensajería unificada se comunicarán con las puertas de enlace IP e IP/PBX a través de una conexión cifrada. Los servidores de mensajería unificada también se comunicarán con otros servidores de Exchange 2010, como los servidores de acceso de cliente y los servidores Transporte de concentradores, a través de una conexión cifrada que usa la TLS mutua. No obstante, la TLS mutua sólo se usará para cifrar el tráfico o los mensajes que se envíen desde el servidor de mensajería unificada a un servidor Transporte de concentradores.
Importante
Para poder habilitar la TLS mutua entre una puerta de enlace IP de mensajería unificada y un plan de marcado que esté funcionando en modo seguro, primero debe configurar la puerta de enlace IP de mensajería unificada con un FQDN de tal modo que esté atenta al puerto 5061. Para realizar dicha configuración, ejecute el siguiente comando: Set-UMIPGateway -Identity MyUMIPGateway -Port 5061.
Volver al principio
IPsec
IPsec también usa certificados para cifrar datos. Proporciona una línea de defensa clave contra los ataques a redes privadas e Internet.
IPsec tiene los siguientes objetivos:
Proteger los contenidos de los paquetes IP.
Proporcionar protección contra ataques a la red mediante el filtrado de paquetes y la aplicación de comunicaciones de confianza.
Psec es un marco de estándares abiertos que permite garantizar la privacidad y la seguridad de las comunicaciones a través de redes IP gracias al uso de servicios de seguridad criptográfica.
IPsec usa protocolos de seguridad, administración de claves dinámicas y servicios de protección basados en la criptografía. Proporciona resistencia y flexibilidad para proteger las comunicaciones entre equipos de redes privadas, dominios, sitios, sitios remotos, redes externas y clientes de acceso telefónico. Se puede usar incluso para bloquear la recepción o la transmisión de tipos específicos de tráfico.
IPsec está basado en un modelo de seguridad de extremo a extremo que establece confianza y seguridad desde una dirección IP origen a una dirección IP destino. La dirección IP como tal no tiene que considerarse una identidad. En su lugar, el sistema que está detrás de la dirección IP posee una identidad que se valida mediante un proceso de autenticación. Los únicos equipos que deben saber que el tráfico está protegido son el emisor y el receptor. Cada equipo se encarga de la seguridad en su extremo correspondiente y funciona bajo el supuesto de que el medio en el que tiene lugar la comunicación no es seguro. Los equipos que enrutan datos sólo desde el origen hasta el destino no necesitan ser compatibles con IPsec, excepto si se produce una traducción de direcciones de red o un filtrado de paquetes de tipo firewall entre los dos equipos. Esto permite que IPsec se implemente correctamente para los siguientes escenarios organizativos:
LAN De cliente a servidor, de servidor a servidor y de servidor a dispositivo VoIP
WAN De enrutador a enrutador y de puerta de enlace a puerta de enlace
Acceso remoto Clientes de acceso telefónico y acceso a Internet desde redes privadas
Normalmente, los dos lados necesitan la configuración de IPsec para establecer opciones y parámetros de seguridad que permitan que los dos sistemas se pongan de acuerdo en cómo contribuir a proteger el tráfico entre ellos. Esto se conoce como directiva IPsec. El servidor Microsoft Windows 2000 Windows XP, Windows Server 2003 y las implementaciones del sistema operativo Windows Server 2008 de IPsec están basados en estándares industriales que han sido desarrollados por el grupo de trabajo de ingeniería de Internet (IETF) para IPsec. Microsoft y Cisco Systems, Inc. desarrollaron conjuntamente partes de los servicios relacionados con IPsec. Para obtener más información acerca de cómo configurar directivas de IPsec, consulte Creación, modificación y asignación de directivas IPsec (en inglés).
Para obtener más información acerca de IPsec, consulte IPSec Concepts (en inglés).
Advertencia
Si ya tiene directivas de IPsec implementadas en la red, debe excluir las puertas de enlace IP y las IP PBX de las mismas. En caso contrario, por cada 3 segundos de correo de voz habrá una interrupción de 1 segundo en la transmisión de voz. Esto es un problema conocido y ya existe una revisión para Windows Server 2003. Para obtener más información acerca de esta revisión, consulte Cómo simplificar la creación y el mantenimiento de los filtros de seguridad del Protocolo de Internet (IPsec) en Windows Server 2003 y Windows XP (en inglés).
Planes de marcado de mensajería unificada y seguridad de VoIP
Los servidores de mensajería unificada se pueden comunicar con puertas de enlace IP, IP PBX y otros equipos que ejecutan Exchange 2010 en modo no protegido, protegido con SIP o simplemente protegido, en función de cómo se haya configurado el plan de marcado de la mensajería unificada. Un servidor de mensajería unificada puede operar en cualquier modo que esté configurado en un plan de marcado porque está configurado para escuchar, al mismo tiempo, tanto las solicitudes no seguras en el puerto TCP 5060, como las solicitudes seguras en el puerto TCP 5061. Un servidor de mensajería unificada puede estar asociado a un plan de marcado de mensajería unificada o a varios, y también puede estar asociado a planes de marcado con parámetros de seguridad de VoIP distintos. Un servidor de mensajería unificada puede estar asociado a planes de marcado configurados para usar una combinación del modo no seguro, seguro con SIP o seguro.
De forma predeterminada, al crear un plan de marcado de mensajería unificada, éste establece la comunicación en modo no seguro, por lo que los servidores de mensajería unificada que están asociados a dicho plan enviarán y recibirán datos de puertas de enlace IP, IP PBX y demás equipos de Exchange 2010 sin usar el cifrado. En el modo no seguro, ni el canal de medios con Protocolo de transporte en tiempo real (RTP) ni la información de señalización en SIP están cifrados.
Se puede configurar un servidor de mensajería unificada para que use la TLS mutua y cifre el tráfico de SIP y RTP que envía a otros dispositivos y servidores, y recibe de éstos. Cuando se agrega un servidor de mensajería unificada a un plan de marcado de mensajería unificada y este último se configura para que use el modo protegido con SIP, sólo se cifrará el tráfico de señalización de SIP, mientras que los canales de medios con RTP seguirán usando TCP. TCP no está cifrado. No obstante, si se agrega un servidor de mensajería unificada a un plan de marcado y éste se configura para usar el modo seguro, se cifrarán el tráfico de señalización de SIP y los canales de medios RTP. Un canal de medios de señalización seguro que usa el Protocolo de transporte en tiempo real seguro (SRTP) también usará la TLS mutua para cifrar los datos de VoIP.
Se puede configurar el modo de seguridad de VoIP al crear un nuevo plan de marcado o después de haber creado uno mediante la Consola de administración de Exchange o el cmdlet Set-UMDialPlan. Si configura el plan de marcado de mensajería unificada para que use el modo seguro o seguro con SIP, los servidores de mensajería unificada asociados a dicho plan cifrarán el tráfico de señalización de SIP o los canales de medios de RTP, o ambos. No obstante, para poder enviar datos cifrados a un servidor de mensajería unificada y desde éste, deberá configurar correctamente el plan de marcado de mensajería unificada, mientras que los dispositivos tales como puertas de enlace IP o IP PBX deberán admitir la TLS mutua.
Puede usar el cmdlet Get-UMDialPlan en el Shell de administración de Exchange para determinar la configuración de seguridad de un plan de marcado de mensajería unificada específico. Si el parámetro de seguridad de VoIP está habilitado, puede comprobar que el Servicio de mensajería unificada de MicrosoftExchange se ha iniciado en modo seguro con sólo consultar el registro de eventos de la aplicación para ver si se han registrado los eventos de información 1114 y 1112.
Importante
Si está configurando una TLS mutua para cifrar datos que se intercambian entre una puerta de enlace IP Dialogic modelo 2000 o 4000, deberá usar la plantilla de certificado Computer V3 que admite la autenticación tanto de servidor como de cliente. La plantilla de certificado de servidor web que admite una autenticación de servidor sólo funcionará correctamente con puertas de enlace IP Dialogic 1000 y 3000, puertas de enlace IP AudioCodes y Microsoft Office Office Communications Server 2007.
Volver al principio
Modo en que la mensajería unificada determina la seguridad y selecciona los certificados
Cuando se inicia el Servicio de mensajería unificada de MicrosoftExchange, éste comprueba el plan de marcado de mensajería unificada y la configuración del parámetro VoipSecurity, e identifica si se debe iniciar en modo protegido o no protegido. Si determina que debe iniciar en un modo seguro, también establece si tiene acceso a los certificados necesarios. Si el servidor de mensajería unificada no se asocia con ningún plan de marcado de mensajería unificada, determina el modo que se inicia teniendo en cuenta el parámetro StartSecured en el archivo Msexchangeum.config. Este parámetro se puede establecer con un valor de 0 o 1. Un valor de 1 inicia el servidor de mensajería unificada mediante cifrado para proteger el tráfico de VoIP. Un valor de 0 inicia el servidor, pero no se usará cifrado para proteger el tráfico de VoIP. Si desea cambiar el comportamiento de inicio del servidor de mensajería unificada de protegido a no protegido o viceversa, puede asociar el servidor a los planes de marcado de mensajería unificada adecuados. También puede cambiar la configuración en el archivo de configuración Msexchangeum.config y reiniciar el servicio de mensajería unificada de Microsoft Exchange.
Si el servidor de mensajería unificada de Microsoft Exchange se inicia en modo no seguro, se iniciará correctamente. Sin embargo, asegúrese de comprobar que las puertas de enlace IP y los IP PBX también se ejecuten en modo no seguro. Asimismo, si desea poner a prueba la conectividad del servidor de mensajería unificada en modo no seguro, use el cmdlet Test-UMConnectivity con el parámetro -Secured:false.
Si el Servicio de mensajería unificada de Microsoft Exchange se inicia en modo seguro, consultará el almacén local de certificados para dar con un certificado válido que le permita usar la TLS mutua y habilitar el cifrado. El servicio primero buscará un certificado de PKI o comercial y, si no encuentra uno adecuado, buscará un certificado autofirmado. Si no encuentra ningún certificado de PKI, ni comercial ni autofirmado, el Servicio de mensajería unificada de MicrosoftExchange creará un certificado autofirmado para poder usarlo al iniciar en modo seguro. Si el servidor de mensajería unificada se inicia en modo no seguro, no hará falta ningún certificado.
Todos los detalles del certificado que se usa para iniciar en modo seguro se registran cada vez que se usa o que se cambia. La información que se registra incluye, entre otros, los siguientes detalles:
Nombre del emisor
Número de serie
Huella digital
La huella digital es el hash del Algoritmo hash seguro (SHA-1), que se puede usar para identificar de forma única el certificado usado. A continuación, puede exportar (desde el almacén local de certificados) el certificado que usa el Servicio de mensajería unificada de MicrosoftExchange para el inicio en modo seguro y luego importarlo de las puertas de enlace IP e IP PBX de la red al almacén de certificados de confianza.
Una vez que se ha encontrado un certificado adecuado y se ha usado sin que se haya producido ningún cambio adicional, el Servicio de mensajería unificada de MicrosoftExchange registrará un evento un mes antes de que dicho certificado expire. Si no realiza ningún cambio en el certificado durante este tiempo, el Servicio de mensajería unificada de MicrosoftExchange registrará un evento al día hasta que expire el certificado y uno al día después de que haya expirado.
Cuando un servidor de mensajería unificada está buscando un certificado para que la TLS mutua establezca un canal cifrado, buscará en el almacén de certificados raíz de confianza. Si hay varios certificados válidos y de diferentes emisores, el servidor de mensajería unificada elegirá el certificado válido al que le quede más tiempo antes de expirar. Si existen varios certificados, el servidor de mensajería unificada los elegirá en función del emisor y de la fecha de expiración. El servidor de mensajería unificada buscará un certificado válido en este orden:
Certificado de PKI o comercial con la fecha de expiración más lejana.
Certificado de PKI o comercial con la fecha de expiración más cercana.
Certificado autofirmado con la fecha de expiración más lejana.
Certificado autofirmado con la fecha de expiración más próxima. Se necesita un certificado autofirmado, PKI o comercial válido. Si no se encuentra un certificado válido, el servidor de mensajería unificada generará un certificado autofirmado. El servidor de mensajería unificada necesita un certificado válido para cifrar el tráfico de VoIP siempre que opera en modo seguro con SIP o en modo seguro.
Importante
Al instalar un nuevo certificado en un servidor de acceso de cliente usado para cifrar datos de Reproducir en el teléfono entre el servidor de acceso de cliente y un servidor de mensajería unificada, se debe ejecutar el comando IISreset desde un símbolo del sistema para cargar el certificado correcto.
Volver al principio
© 2010 Microsoft Corporation. Reservados todos los derechos.