Seguridad y Skype Empresarial en línea
Importante
Skype Empresarial Online operado por 21Vianet en China se retirará el 1 de octubre de 2023. Si aún no ha actualizado sus usuarios de Skype Empresarial Online, se programarán automáticamente para una actualización asistida. Si quiere actualizar su organización a Teams usted mismo, le recomendamos que empiece a planear la ruta de actualización hoy mismo. Recuerde que una actualización correcta alinea la preparación técnica y de usuario, por lo que debe asegurarse de aprovechar nuestras instrucciones de actualización mientras se desplaza a Teams.
Skype Empresarial Online, excluyendo el servicio operado por 21Vianet en China, se retiró el 31 de julio de 2021.
Skype Empresarial Online (SfBO), como parte de los servicios de Microsoft 365 y Office 365, sigue todos los procedimientos y procedimientos recomendados de seguridad, como la seguridad a nivel de servicio a través de defensa en profundidad, controles del cliente dentro del servicio, protección de la seguridad y procedimientos recomendados operativos. Para obtener detalles completos, consulta el Centro de confianza de Microsoft (https://microsoft.com/trustcenter).
Confiable por su diseño
Skype Empresarial Online está diseñado y desarrollado conforme al ciclo de vida de desarrollo de seguridad (SDL, Security Development Lifecycle) de Trustworthy Computing de Microsoft, que se describe en https://www.microsoft.com/sdl/default.aspx. El primer paso para crear un sistema de comunicaciones unificadas más seguro fue diseñar modelos de amenazas y probar cada característica tal como se diseñó. Se integraron múltiples mejoras relacionadas con la seguridad en el proceso y las prácticas de codificación. Las herramientas de tiempo de compilación detectan excesos de almacenaje y otras amenazas de seguridad antes de que el código se incorpore al producto final. Es imposible diseñar contra todas las amenazas de seguridad desconocidas. Ningún sistema puede garantizar una seguridad completa. Sin embargo, como el desarrollo del producto se basó en principios de diseño seguro desde el inicio, Skype Empresarial Online cuenta con tecnologías de seguridad estándar del sector como parte fundamental de su infraestructura.
Confiable de forma predeterminada
En Skype Empresarial Online, las redes de comunicación están encriptadas de forma predeterminada. Al exigir que todos los servidores usen certificados y mediante OAUTH, TLS, Protocolo seguro de transporte de Real-Time (SRTP) y otras técnicas de cifrado estándar del sector, incluido el cifrado de cifrado avanzado (AES) de 256 bits, todos los datos de Skype Empresarial Online están protegidos en la red.
¿Cómo gestiona SfBO las amenazas comunes de seguridad?
Esta sección identifica las amenazas más comunes para la seguridad del servicio SfBO y cómo Microsoft mitiga cada amenaza.
Ataque mediante clave conocida
Una clave es un código o número secreto que se usa para cifrar, descifrar o comprobar información secreta. Existen dos claves importantes en uso en la infraestructura de clave pública (PKI, Public Key Infrastructure) que deben ser consideradas: la clave privada que tiene cada titular de certificado y la clave de sesión, que se utiliza después de una identificación exitosa y de un intercambio de claves de sesión entre las partes que se estén comunicando. Un ataque de clave comprometida se produce cuando el atacante consigue la clave privada o de sesión. Cuando el atacante consigue la clave, puede usarla para descifrar datos cifrados sin que el remitente lo sepa.
Skype Empresarial Online usa las características de la PKI del sistema operativo Windows Server para proteger los datos clave usados para el cifrado de las conexiones de Seguridad de la capa de transporte (TLS). Las claves que se usan para cifrar medios se intercambian a través de conexiones TLS.
Ataque por denegación de servicio de red
El ataque por denegación de servicio tiene lugar cuando el atacante impide el uso y el funcionamiento normales de red a usuarios válidos. Con un ataque por denegación de servicio, el atacante puede:
- Enviar datos no válidos a las aplicaciones y los servicios que se ejecutan en la red que sufre el ataque para interrumpir su funcionamiento normal.
- Enviar una gran cantidad de tráfico, lo que sobrecarga el sistema hasta que deja de responder o responde lentamente a las solicitudes legítimas.
- Ocultar las pruebas de los ataques.
- Impedir que los usuarios obtengan acceso a los recursos de la red.
SfBO mitiga estos ataques ejecutando protección de red DDOS de Azure y limitación de solicitudes de cliente desde los mismos puntos de conexión, subredes y entidades federadas.
Interceptación
La interceptación se produce cuando un atacante obtiene acceso a la ruta de datos en una red y puede supervisar y leer el tráfico. Este tipo de ataque también se denomina rastreo o espionaje. Si el tráfico se produce como texto sin formato, el atacante puede leerlo cuando obtiene acceso a la ruta. Un ejemplo es un ataque que se realiza al controlar un enrutador de la ruta de acceso a los datos.
SfBO usa TLS mutuo (MTLS) para las comunicaciones de servidor dentro de Microsoft 365 o Office 365 y TLS desde los clientes al servicio, lo que hace que este ataque sea difícil de lograr dentro del período de tiempo en el que una conversación determinada podría ser atacada. TLS autentica todas las partes y cifra todo el tráfico. Esto no impide el escucha, pero el atacante no puede leer el tráfico a menos que se rompa el cifrado.
El protocolo TURN se usa para lograr objetivos relacionados con elementos multimedia en tiempo real. El protocolo TURN no impone el cifrado del tráfico, y la información que envía está protegida por la integridad del mensaje. Aunque está abierta a escuchas, la información que envía (es decir, las direcciones IP y el puerto) se puede extraer directamente consultando las direcciones de origen y de destino de los paquetes. El servicio SfBO garantiza que los datos sean válidos comprobando la integridad del mensaje mediante la clave derivada de algunos elementos, incluida una contraseña TURN, que nunca se envía en texto claro. SRTP (Secure Real-Time Transport Protocol) se utiliza para el tráfico de elementos multimedia y también está encriptado.
Suplantación de identidad (imitación de direcciones IP)
La suplantación de identidad (spoofing) se produce cuando el atacante identifica y usa una dirección IP de una red, un equipo o un componente de red sin tener autorización para ello. Un ataque con éxito permite al atacante operar como si el atacante fuera la entidad que normalmente se identifica por la dirección IP. En el contexto de Microsoft Lync Server 2010, esta situación solo entra en juego si un administrador ha realizado las dos acciones siguientes:
- Conexiones configuradas que admiten solo el Protocolo de control de transmisión (TCP) (que no se recomienda, porque las comunicaciones TCP no están cifradas).
- Ha marcado las direcciones IP de esas conexiones como hosts de confianza.
Este es un problema menor para las conexiones TLS (Seguridad de la capa de transporte), puesto que TLS autentica todas las partes y cifra todo el tráfico. El uso de TLS evita que un atacante suplante las direcciones IP en una conexión concreta (por ejemplo, conexiones Mutual TLS). Pero un atacante podría suplantar la dirección del servidor DNS que usa SfBO. Sin embargo, como la autenticación en SfBO se realiza con certificados, un atacante no tendría un certificado válido requerido para suplantar la identidad de una de las partes en la comunicación.
Ataque de intermediario
Un ataque de tipo "Man in the middle" se produce cuando un atacante desvía la comunicación entre dos usuarios a través del equipo del atacante sin que lo sepan esos dos usuarios. El atacante puede supervisar y leer el tráfico antes de enviarlo al destinatario previsto. Cada usuario de la comunicación envía tráfico sin saberlo y recibe tráfico del atacante, todo mientras piensa que se comunica solo con el usuario deseado. Esto puede suceder si un atacante modifica los Servicios de dominio de Active Directory para agregar su servidor como un servidor de confianza o modifica el Sistema de nombres de dominio (DNS) para que los clientes se conecten al servidor a través del atacante.
También se puede producir un ataque "Man in the middle" con tráfico de elementos multimedia entre dos clientes, excepto que en SfBO las transmisiones de uso compartido y punto a punto de audio, video y aplicaciones se encriptan con SRTP, usando claves criptográficas que se negocian entre pares empleando el protocolo de inicio de sesión (SIP, Session Initiation Protocol) sobre TLS.
Ataque de reproducción RTP
Un ataque de reproducción se produce cuando se intercepta y retransmite una transmisión multimedia válida entre dos usuarios con fines malintencionados. SfBO utiliza SRTP con un protocolo de señalización seguro que protege las transmisiones contra ataques de repetición, permitiendo al receptor mantener un índice de paquetes RTP ya recibidos y comparar cada paquete nuevo con los que ya aparecen en el índice.
Mensajes instantáneos no deseados
El término inglés "spim" hace referencia a los mensajes instantáneos comerciales no deseados o a las solicitudes de suscripción de presencia no deseadas. Si bien estos mensajes por sí mismos no son un peligro para la seguridad de la red, son como mínimo molestos, pueden reducir la disponibilidad y la productividad de los recursos, y podrían llegar a poner en peligro la red. Un ejemplo de ello es el caso de usuarios que se envían solicitudes no deseadas entre sí. Los usuarios pueden bloquearse entre sí para evitarlo, pero con la federación, si se establece un ataque coordinado de este tipo, puede ser difícil de solucionar a menos que se deshabilite la federación para el asociado.
Virus y gusanos
Un virus es una unidad de código cuyo propósito es reproducir más unidades de código similares. Para que funcione, un virus necesita un anfitrión, como un archivo, un correo electrónico o un programa. Al igual que un virus, un gusano es una unidad de código que está codificada para reproducir más unidades de código similares, pero que a diferencia de un virus no necesita un host. Los virus y los gusanos suelen aparecer principalmente durante las transferencias de archivo entre clientes o cuando otros usuarios envían direcciones URL. Si hay un virus en su equipo, podrá, por ejemplo, usar su identidad y enviar mensajes instantáneos en su nombre. Las medidas estándar de seguridad de cliente como los análisis periódicos en busca de virus pueden mitigar este problema.
Información de identificación personal
SfBO tiene el potencial de divulgar información a través de una red pública que podría ser capaz de estar vinculada a una persona. Dicha información se puede desglosar en dos categorías:
- Datos de presencia mejorados Los datos de presencia mejorada son información que un usuario puede elegir compartir o no a través de un vínculo a un socio federado o con contactos dentro de una organización. Estos datos no se comparten con los usuarios de una red de mensajería instantánea pública. Las directivas de cliente y otras opciones de configuración del cliente pueden otorgar algún tipo de control al administrador del sistema. En el servicio SfBO, se puede configurar el modo de privacidad de presencia mejorada para un usuario individual para evitar que los usuarios de SfBO que no estén en la lista de contactos del usuario vean la información de presencia del usuario.
- Datos obligatorios Los datos obligatorios son datos necesarios para el correcto funcionamiento del servidor o del cliente. Se trata de información que es necesaria en un servidor o una red para el enrutamiento, el mantenimiento de estados y la señalización. Las siguientes tablas enumeran los datos que se requieren para que SfBO funcione.
Tabla 1: datos de presencia mejorados
| Datos | Posibles opciones de configuración |
|---|---|
| Datos personales | Nombre, Puesto, Empresa, dirección Email, Zona horaria |
| Números de teléfono | Trabajo, Móvil, Particular |
| Información de calendario | Disponibilidad, aviso de fuera de la ciudad, detalles de la reunión (para aquellos que tienen acceso a su calendario) |
| Estado de presencia | Ausente, Disponible, Ocupado, No molestar, Sin conexión |
Tabla 2: datos obligatorios
| Datos | Posibles opciones de configuración |
|---|---|
| Dirección IP | Dirección real del equipo o dirección traducida |
| URI del SIP | david.campbell@contoso.com |
| Nombre | David Campbell (según se define en Servicios de dominio de Active Directory) |
Marco de seguridad para SfBO
En esta sección se proporciona información general sobre los elementos fundamentales que forman el marco de seguridad de Microsoft SfBO. Dichos elementos son los siguientes:
- Microsoft Entra ID proporciona un único repositorio back-end de confianza para las cuentas de usuario.
- La infraestructura de clave pública (PKI) usa certificados emitidos por entidades de certificación (CA) de confianza para autenticar servidores y garantizar la integridad de los datos.
- La Seguridad de la capa de transporte (TLS), HTTPS sobre SSL (HTTPS) y Mutual TLS (MTLS) permiten la autenticación de los extremos y el cifrado de la mensajería instantánea. Las secuencias de audio, vídeo y uso compartido de aplicaciones punto a punto se cifran y se comprueba su integridad con el protocolo de transporte seguro en tiempo real (SRTP).
- Para la autenticación del usuario se usan los protocolos estándar de la industria, siempre que sea posible.
Los artículos de esta sección describen cómo funciona cada uno de estos elementos fundamentales para mejorar la seguridad del servicio SfBO.
Microsoft Entra ID
Microsoft Entra ID funciones como servicio de directorio de Microsoft 365 y Office 365. Almacena todas las asignaciones de directivas y la información de directorio de usuario.
Infraestructura de clave pública para SfBO
El servicio SfBO se basa en certificados para la autenticación de servidores y para establecer una cadena de confianza entre clientes y servidores y entre los diferentes roles de servidor. La infraestructura de claves públicas (PKI, Public Key Infrastructure) de Windows Server proporciona la infraestructura para establecer y validar esta cadena de confianza.
Los certificados son identificadores digitales. Identifican un servidor por nombre y especifican sus propiedades. Para asegurarse de que la información de un certificado es válida, el certificado debe emitirlo una entidad de certificación (CA) que sea de confianza para clientes u otros servidores que se conecten al servidor. Si el servidor se conecta únicamente a otros clientes y servidores de una red privada, la CA puede ser una CA de empresa. Si el servidor interactúa con entidades ubicadas fuera de la red privada, es posible que se requiera una CA pública.
Incluso si la información incluida en el certificado es válida, es preciso comprobar de alguna manera que el servidor que presenta el certificado es realmente el servidor representado por el certificado. Ahí es donde entra en juego la PKI de Windows.
Cada certificado está asociado a una clave pública. El servidor indicado en el certificado tiene una clave privada correspondiente que solo él conoce. El cliente o servidor que se conecta usa la clave pública para cifrar un fragmento de información aleatorio y enviarlo al servidor. Si el servidor descifra la información y la devuelve como texto sin formato, la entidad que se conecta puede estar segura de que el servidor tiene la clave privada asociada al certificado y, por consiguiente, es el servidor indicado en el certificado.
Puntos de distribución de CRL
SfBO requiere que todos los certificados de servidor contengan uno o más puntos de distribución de lista de revocación de certificados (CRL). Los puntos de distribución CRL (CDP) son ubicaciones desde las que se pueden descargar CRL para comprobar si un certificado no ha sido revocado después de su emisión y todavía se encuentra dentro del período de validez. Un punto de distribución CRL se anota en las propiedades del certificado como una dirección URL y es HTTPS. El servicio SfBO comprueba CRL con cada autenticación de certificado.
Uso mejorado de clave
Todos los componentes del servicio SfBO requieren que todos los certificados de servidor admitan el uso de claves mejorado (EKU) para la autenticación del servidor. La configuración del campo EKU para la autenticación de los servidores significa que el certificado es válido para la autenticación de los servidores. Este EKU es esencial para MTLS.
TLS y MTLS para SfBO
TLS y MTLS ofrecen comunicaciones cifradas y autenticación de puntos de conexión en Internet. SfBO utiliza estos dos protocolos para crear la red de servidores de confianza y para garantizar que todas las comunicaciones a través de esa red están cifradas. Todas las comunicaciones SIP entre los servidores se llevan a cabo a través de MTLS. Las comunicaciones SIP entre el cliente y el servidor se realizan a través de TLS.
TLS permite a los usuarios, mediante su software cliente, autenticar los servidores SfBO a los que se conectan. En una conexión TLS, el cliente solicita un certificado válido del servidor. Para que sea válido, el certificado debe haber sido emitido por una CA que también sea de confianza para el cliente y el nombre DNS del servidor debe coincidir con el nombre DNS del certificado. Si el certificado es válido, el cliente usa la clave pública del certificado para cifrar las claves de cifrado simétricas que se utilizarán para la comunicación, de modo que solo el propietario original del certificado puede usar su clave privada para descifrar el contenido de la comunicación. La conexión resultante es de confianza y, a partir de ese momento, otros servidores o clientes de confianza no los desafían. En este contexto, SSL, tal como se usa con los servicios web, se puede asociar como basada en TLS.
Las conexiones de servidor a servidor se basan en TLS mutua (MTLS) para autenticación mutua. En una conexión MTLS, el servidor de origen de un mensaje y el que lo recibe intercambian certificados procedentes de una CA de confianza para ambos. Los certificados permiten a los servidores demostrarse mutuamente sus identidades. El servicio SfBO sigue este procedimiento.
TLS y MTLS evitan la interceptación y los ataques de intermediario. En los ataques de tipo "Man in the middle", el atacante enruta las comunicaciones entre dos entidades de red a través del equipo del atacante sin que lo sepa ninguna de esas entidades. La especificación de TLS y SfBO de servidores de confianza mitiga el riesgo de un ataque man-in-the middle parcialmente en la capa de la aplicación mediante el cifrado de un extremo a otro coordinado mediante la criptografía de clave pública entre los dos puntos de conexión, y un atacante tendría que tener un certificado válido y de confianza con la clave privada correspondiente y emitido al nombre del servicio al que el cliente se comunica para descifrar la comunicación.
Encriptación para SfBO
SfBO usa TLS y MTLS para cifrar mensajes instantáneos. Todo el tráfico de servidor a servidor necesita MTLS, independientemente de si el tráfico está limitado a la red interna o atraviesa el perímetro de esta.
La siguiente tabla resume el protocolo utilizado por SfBO.
Tabla 3: protección de tráfico
| Tipo de tráfico | rotectado por |
|---|---|
| Servidor a servidor | MTLS |
| Cliente a servidor | TLS |
| Mensajería instantánea y presencia | TLS (si está configurado para TLS) |
| Audio, vídeo y uso compartido de escritorio | SRTP |
| Uso compartido de escritorio (señalización) | TLS |
| Conferencia web | TLS |
| Descarga del contenido de las reuniones, descarga de la libreta de direcciones y expansión de grupos de distribución | HTTPS |
Cifrado de medios
El tráfico de medios se cifra mediante RTP seguro (SRTP), que es un perfil de protocolo de transporte en tiempo real (RTP) que proporciona al tráfico RTP confidencialidad, autenticación y protección contra los ataques de reproducción. SRTP utiliza una clave de sesión creada con un generador de números aleatorios seguros y se intercambia mediante el canal de señalización TLS. Además, los medios que fluyen en ambas direcciones entre el servidor de mediación y el servidor interno del próximo salto también se cifran mediante SRTP.
SfBO genera nombres de usuario/contraseñas para acceder de forma segura a relés multimedia mediante TURN. Los relés multimedia intercambian el nombre de usuario/contraseña a través de un canal SIP protegido con TLS.
FIPS
SfBO utiliza algoritmos compatibles con FIPS para intercambiar claves de cifrado.
Autenticación de usuario y cliente
Un usuario de confianza es aquel cuyas credenciales se han autenticado por Microsoft Entra ID de Microsoft 365 o Office 365.
La autenticación consiste en proporcionar credenciales de usuario a un servicio o servidor de confianza. SfBO utiliza los siguientes protocolos de autenticación, según el estado y la ubicación del usuario.
- La autenticación moderna consiste en la implementación de Microsoft de OAUTH 2.0 para la comunicación de cliente a servidor. Habilita características de seguridad como autenticación basada en certificados, autenticación multifactor y acceso condicional. Para poder usar MA, tanto el inquilino en línea como los clientes deben estar habilitados para MA. Los inquilinos de SfBO creados después de mayo de 2017 tienen la MA habilitada por defecto. Siga las instrucciones aquí incluidas para habilitar la MA de los inquilinos creados antes de esa fecha. Los siguientes clientes son compatibles con MA: cliente de Skype Empresarial 2015 o 2016, Skype Empresarial para Mac, cliente de Lync 2013, teléfonos IP 3PIP, iOS y Android.
- El id. de organización se usa cuando la autenticación moderna no está habilitada (o no está disponible).
- Protocolo de autenticación implícita para los usuarios denominados anónimos. Los usuarios anónimos son usuarios externos que no han reconocido las credenciales de Active Directory pero que han sido invitados a una conferencia local y poseen una clave de conferencia válida. La autenticación de resumen no se usa para otras interacciones del cliente.
La autenticación SfBO consta de dos fases:
- Se establece una asociación de seguridad entre el cliente y el servidor.
- El cliente y el servidor utilizan la asociación de seguridad existente para firmar los mensajes que envían y comprobar los que reciben. Los mensajes no autenticados de un cliente no se aceptan cuando se habilita la autenticación en el servidor.
La confianza en un usuario se adjunta a cada mensaje que procede del usuario, no a la identidad del usuario. El servidor comprueba cada mensaje para determinar si las credenciales de usuario son válidas. Si las credenciales de usuario son válidas, el mensaje no es solo el primer servidor que lo recibe, sino el resto de los servidores de SfBO.
Los usuarios con credenciales válidas emitidas por un socio federado son de confianza pero, de manera opcional, algunas restricciones adicionales impiden que disfruten de todos los privilegios otorgados a los usuarios internos.
Para la autenticación multimedia, los protocolos ICE y TURN también usan el desafío de autenticación implícita que se describe en la RFC del IETF referente a TURN. Para obtener más información, consulta Recorrido multimedia.
Los certificados de cliente proporcionan un modo alternativo para que los usuarios se autentiquen mediante SfBO. En vez de proporcionar un nombre de usuario y una contraseña, los usuarios cuentan con un certificado y una clave privada correspondiente al certificado necesario para resolver un desafío criptográfico.
Herramientas de administración de Windows PowerShell y SfBO
En SfBO, los administradores de TI pueden administrar sus servicios a través del portal de administración de O365 o mediante el uso de Tenant Remote PowerShell (TRPS). Los administradores de inquilinos usan la Autenticación moderna para autenticarse en TRPS.
Configurar el acceso a SfBO en su límite de Internet
Para que SfBO funcione correctamente (los usuarios que pueden unirse a reuniones, etc.), los clientes necesitan configurar su acceso a Internet de modo que se permita el tráfico UDP y TCP saliente a los servicios en la nube sfBO. Para obtener más información, consulte aquí: https://support.office.com/article/Office-365-URLs-and-IP-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2#bkmk_lyo
UDP 3478-3481 y TCP 443
Los clientes usan los puertos UDP 3478-3481 y TCP 443 para solicitar el servicio A/V Edge. El cliente utiliza estos dos puertos para asignar puertos UDP y TCP, respectivamente, para que la ubicación remota se conecte a ellos. Para acceder al servicio perimetral de A/V, el cliente debe primero haber establecido una sesión de señalización SIP autenticada con el registrador SfBO para obtener las credenciales de autenticación del servicio perimetral A/V. Estos valores se envían a través del canal de señalización protegido con TLS y se generan por ordenador para reducir el riesgo de ataques de diccionario. Los clientes pueden usar estas credenciales para la autenticación de texto implícita con el servicio A/V Edge para asignar puertos al objeto de usarlos en una sesión de elementos multimedia. El cliente envía una solicitud de asignación inicial y es respondido con un mensaje 401 nonce/desafío por parte del servicio A/V Edge. El cliente envía una segunda asignación que contiene el nombre de usuario y un código hash de autenticación de mensaje hash (HMAC), hash del nombre de usuario y nonce.
También existe un mecanismo de número de secuencia para prevenir ataques de repetición. El servidor calcula el HMAC previsto en función de su propia información sobre el nombre de usuario y la contraseña. Si los valores HMAC coinciden, se realiza el procedimiento de asignación. De lo contrario, el paquete se descarta. Este mecanismo HMAC también se aplica a mensajes posteriores en la misma sesión de llamada. Este nombre de usuario/contraseña tiene una duración máxima de ocho horas, momento en el que el cliente vuelve a adquirir un nuevo nombre de usuario/contraseña para llamadas posteriores.
UDP/TCP 50.000-59.999
Se utiliza TCP 50 000 de salida para SfBO para compartir aplicaciones y escritorios y transferencia de archivos. Los rangos de puertos UDP/TCP 50 000-59 999 se utilizan para sesiones de elementos multimedia con socios de Microsoft Office Communications Server 2007 que requieren el servicio NAT/cortafuegos transversal desde el servicio A/V Edge. Dado que el servicio perimetral A/V es el único proceso que usa estos puertos, el tamaño del intervalo de puertos no indica la superficie potencial de ataque. Una buena práctica de seguridad es minimizar siempre el número total de puertos de escucha; se consigue no ejecutando servicios de red innecesarios. Si un servicio de red no se está ejecutando, no es explotable por un atacante remoto y la superficie de ataque del equipo host se reduce. Sin embargo, dentro de un solo servicio, reducir el número de puertos no proporciona la misma ventaja. El software de servicio A/V Edge no está más expuesto al ataque con 10 000 puertos abiertos que con 10. La asignación de puertos dentro de este rango se hace aleatoriamente y los puertos no asignados actualmente no escuchan los paquetes.
Transversal de tráfico A/V de usuario externo
La habilitación de usuarios externos y usuarios internos para intercambiar elementos multimedia requiere un servicio perimetral de acceso para administrar la señalización SIP necesaria para configurar y anular una sesión. También requiere un servicio perimetral A/V que actúe como relé para la transferencia de los elementos multimedia. La secuencia de llamadas se muestra en la figura siguiente.
Un usuario recibe un correo electrónico que contiene una invitación para unirse a una reunión sfBO. El correo electrónico contiene una clave de conferencia y una URL basada en HTTP vinculada a la conferencia. Tanto la clave como la URL son únicas para una reunión determinada.
El usuario inicia el procedimiento de unión haciendo clic en la dirección URL de la reunión en el correo electrónico, que inicia un proceso de detección de cliente en el equipo del usuario. Si se detecta al cliente, se inicia. Si no se detecta, el usuario se redirige al cliente web.
El cliente SfBO envía un SIP INVITE que contiene las credenciales del usuario. Un usuario federado o remoto se une a una conferencia con sus credenciales de empresa. Para un usuario federado, SIP INVITE se envía primero a su servidor principal, que autentica al usuario y reenvía el INVITE a SfBO. Se requiere que un usuario anónimo supere la autenticación de texto implícita.
SfBO autentica al usuario remoto o anónimo y lo notifica al cliente. Como se ha indicado en el paso 2, los usuarios federados que se unen a una conferencia son autenticados por su empresa.
El cliente envía una solicitud INFO para agregar al usuario a la conferencia A/V.
Las conferencias A/V envían una respuesta Agregar usuario que contiene el token para presentar al servicio perimetral de conferencia de A/V, entre otra información.
[Nota] Todo el tráfico SIP anterior fluía a través del servicio perimetral de acceso.
El cliente se conecta al servidor de conferencia A/V, que valida el token y transmite la solicitud (que contiene otro token de autorización) al servidor de conferencia A/V interno. El servidor de conferencia A/V valida el token de autorización que emitió originalmente mediante el canal SIP para garantizar que un usuario válido se une a la conferencia.
Entre el cliente y el servidor de conferencia de A/V, se negocia y configura una conexión multimedia a través de SRTP.
Un usuario recibe un correo electrónico que contiene una invitación para unirse a una reunión sfBO. El correo electrónico contiene una clave de conferencia y una URL basada en HTTP vinculada a la conferencia. Tanto la clave como la URL son únicas para una reunión determinada.
Medidas de seguridad de la federación para sfBO
La federación permite que su organización se comunique con otras organizaciones para compartir presencia y mensajería instantánea. En SfBO, la federación está activada de forma predeterminada. Sin embargo, los administradores de inquilinos tienen la capacidad de controlar esto a través del portal de Microsoft 365 o Office 365 Admin. Más información.
Atajar amenazas a las conferencias de SfBO
SfBO permite que los usuarios empresariales creen y se unan a conferencias web en tiempo real. Los usuarios empresariales también pueden invitar a usuarios externos que no tengan una cuenta de Microsoft Entra ID, Microsoft 365 o Office 365 para que participen en estas reuniones. Los usuarios que son empleados de socios federados con una identidad segura y autenticada también pueden unirse a las reuniones y, si se les promociona para hacerlo, pueden actuar como presentadores. Los usuarios anónimos no pueden crear o unirse a una reunión como moderador, pero pueden ser promovidos a moderador después de unirse.
Permitir que usuarios externos participen en las reuniones de SfBO aumenta considerablemente el valor de esta función, pero también implica algunos riesgos de seguridad. Para atajar estos riesgos, SfBO proporciona las siguientes garantías adicionales:
- Los roles de los participantes determinan los privilegios de control de la conferencia.
- Los tipos de participantes le permiten limitar el acceso a reuniones específicas.
- Los tipos de reunión definidos determinan qué tipos de participantes pueden asistir.
- La programación de conferencias está restringida a los usuarios que tienen una cuenta de Microsoft Entra y una licencia SfBO.
- Usuarios anónimos, es decir, no autenticados, que quieren unirse a un marcado de conferencia de acceso telefónico local a uno de los números de acceso a la conferencia y, a continuación, se les pide que escriban el id. de conferencia. A los usuarios anónimos sin autenticar también se les pide que registren su nombre. El nombre grabado identifica a los usuarios sin autenticar en la conferencia. Los usuarios anónimos no se admiten a la conferencia hasta que se haya unido al menos un líder o usuario autenticado y no se les puede asignar un rol predefinido.
Roles de los participantes
Los participantes de la reunión se dividen en tres grupos, cada uno con sus propios privilegios y restricciones:
- Organizador: el usuario que crea una reunión, independientemente de si es improvisada o programada. Un organizador debe ser un usuario empresarial autenticado y tener control sobre todos los aspectos del usuario final de una reunión.
- Moderador: un usuario al que se autoriza la presentación de información durante una reunión con cualquier elemento multimedia admitido. El organizador de la reunión es, por definición, también un moderador y determina quién más puede serlo. Un organizador puede determinarlo cuando se programa una reunión o mientras se está llevando a cabo.
- Asistente Un usuario al que se le ha invitado a asistir a una reunión pero que no está autorizado para actuar como moderador.
Un moderador también puede promover a un asistente al rol de moderador durante la reunión.
Tipos de participantes
Los participantes en la reunión también se clasifican por ubicación y credenciales. Puede utilizar estas dos características para especificar qué usuarios pueden tener acceso a reuniones específicas. Los usuarios se pueden dividir, en términos generales, en las siguientes categorías:
Usuarios que pertenecen al inquilino Estos usuarios tienen una credencial en Microsoft Entra ID para el inquilino.
- Inside corpnet – Estos usuarios se unen desde dentro de la red corporativa.
- Usuarios remotos: estos usuarios se unen desde fuera de la red corporativa. Pueden incluir empleados que trabajan desde casa o mientras viajan, y otros, como empleados de proveedores de confianza, a quienes se les han otorgado credenciales empresariales por sus términos de servicio. Los usuarios remotos pueden crear y unirse a conferencias y actuar como presentadores.
Usuarios que no pertenecen al inquilino Estos usuarios no tienen credenciales en Microsoft Entra ID para el inquilino.
- Usuarios federados : los usuarios federados poseen credenciales válidas con socios federados y, por tanto, se tratan como autenticados por SfBO. Los usuarios federados pueden unirse a conferencias y promoverse a los moderadores después de unirse a la reunión, pero no pueden crear conferencias en empresas con las que están federados.
- Usuarios anónimos : los usuarios anónimos no tienen una identidad de Active Directory y no están federados con el inquilino.
Los datos de clientes muestran que muchas conferencias implican a usuarios externos. Esos clientes también quieren confirmar la identidad de los usuarios externos antes de permitir que se unan a una conferencia. Como se describe en la siguiente sección, SfBO limita el acceso a la reunión a los tipos de usuarios permitidos y requiere que todos los tipos de usuario presenten las credenciales adecuadas al entrar en una reunión.
Admisión de los participantes
En SfBO, los usuarios anónimos se transfieren a un área llamada sala de espera. A continuación, los presentadores pueden admitir a estos usuarios en la reunión o rechazarlos. Estos usuarios son transferidos a la sala de espera, el líder es informado, y a continuación esperan a que un líder los acepte o rechace o hasta que su conexión caduque. Mientras están en la sala de espera escuchan música.
De forma predeterminada, los participantes que llaman desde la PSTN pasan directamente a la reunión, pero esta opción se puede cambiar para obligarlos a ir a la sala de espera.
Los organizadores de la reunión controlan si los participantes pueden unirse a una reunión sin aguardar en la sala de espera. Cada reunión puede configurarse para permitir el acceso mediante cualquiera de los métodos siguientes:
- Solo yo, el organizador de la reunión Todos los participantes, excepto el organizador, deben esperar en la sala de espera hasta que se le admita en la reunión.
- Personas invito desde mi empresa Cualquier persona de su empresa puede acceder a la reunión directamente, incluso si no se le invita.
- Cualquier persona de mi organización Todos los usuarios de SfBO del espacio empresarial de Microsoft 365 o Office 365 pueden unirse a la reunión sin tener que esperar en la sala de espera, incluso si los que no están en la lista de distribución. El resto, incluidos todos los usuarios externos y anónimos, deben aguardar en la sala de espera hasta ser admitidos.
- Nadie Cualquier persona (sin restricciones) que tenga acceso al vínculo de la reunión accederá directamente a la reunión. Cuando se especifica cualquier método, excepto "Solo el organizador" (bloqueado), el organizador de la reunión también puede establecer que las personas que llamen por teléfono no pasen por la sala de espera.
Capacidades del presentador
Los organizadores de la reunión controlan si los participantes pueden realizar presentaciones durante una reunión. Cada reunión puede configurarse para limitar los presentadores, según estas opciones:
- Solo organizador Solo el organizador de la reunión puede presentar.
- Gente de mi empresa Todos los usuarios internos pueden presentar.
- Todas las personas, incluidas las de fuera de mi empresa Todas las personas (sin restricciones) que se unan a la reunión pueden presentar.
- Personas elijo El organizador de la reunión especifica qué usuarios pueden presentar agregándolos a una lista de moderadores.