Información general sobre la seguridad
Microsoft eCDN es un servicio compatible con M365. Esto significa que sigue todos los mismos estándares de seguridad mantenidos por cualquier otro servicio M365.
En este documento se resaltan varios artículos que son específicos de la seguridad a medida que se aplica a la entrega de streaming de vídeo.
Microsoft eCDN es una solución híbrida, lo que significa que Microsoft eCDN se emplea en combinación con un servidor HTTP tradicional, al tiempo que sigue aprovechando la infraestructura de seguridad existente (tokens, claves, cookies, etc.) que ya está en vigor.
En términos de comunicación, hay dos canales de comunicación principales:
Entre pares; Los elementos del mismo nivel están conectados entre sí a través del canal de datos WebRTC, que es un túnel seguro que usa el protocolo SCTP a través del cifrado DTLS.
Entre cada visor y el back-end de Microsoft eCDN a través de una conexión webSocket segura que usa el cifrado TLS.
Ambos canales usan protocolos de seguridad de red estándar del sector, por lo que no se pueden poner en peligro los datos enviados entre dos visores ni los metadatos enviados entre cada visor y el back-end del servicio.
Además de lo anterior, el servicio tiene características de seguridad adicionales que se pueden habilitar, en función de los requisitos individuales, que se explican a continuación.
Autenticación del visor
Normalmente, cualquier visor puede conectarse al back-end de Microsoft eCDN y participar en la red P2P. Esto es aceptable en la mayoría de los casos de uso, pero algunos clientes pueden preferir limitar qué visores pueden conectarse al servicio.
En estos casos, el back-end puede autenticar a los visores directamente, además de los mecanismos de autenticación que ya puedan existir en el lado del proveedor de contenido. Los mecanismos de autenticación que Microsoft eCDN ha implementado impiden que los visores no autorizados accedan al contenido y a los metadatos que existan en la red punto a punto.
Lista de permitidos de dominio
La manera más rápida y sencilla de impedir que la mayoría de los visores no deseados participen en el emparejamiento es permitir explícitamente la inclusión en la lista de dominios específicos desde los que los visores pueden conectarse al back-end del servicio. Esto significa que los visores que intentan conectarse al servicio desde otros dominios no permitidos están bloqueados.
Guía paso a paso:
Vaya a la página de configuración Plataformas de terceros en la consola de administración.
Agregue los dominios (los que se cargan los scripts de servicio) en el cuadro "Lista de permitidos del sitio web", como se muestra a continuación.
Y eso es todo. Se bloqueará cualquier visor que intente conectarse al servicio con el identificador de inquilino desde un dominio que no aparece en la lista.
Lista de permitidos de IP del usuario final
Otro medio por el que los administradores pueden impedir que los visores no deseados participen en el emparejamiento es permitir solo el acceso al servicio desde una lista predefinida de direcciones IP públicas. Esto es similar a la característica "domain allowlisting" anterior, pero esta vez se permiten las direcciones IP públicas de los visores.
Guía paso a paso:
Vaya a la página Configuración de seguridad en la consola de administración.
Agregue las direcciones IP públicas o los intervalos IP deseados en el cuadro "Lista de direcciones IP permitidas de los usuarios finales" en uno de los formatos admitidos, como se muestra a continuación.
Y eso es todo. Se bloquea cualquier visor que intente conectarse al servicio con el identificador de inquilino con una dirección IP que no está permitida.
Formatos admitidos:
Ip única : escriba cada dirección IP en una nueva línea o agréguelas una por una, haciendo clic en el botón "Agregar direcciones IP" después de cada una de ellas. Ejemplo: 1.1.1.1
CIDR : escriba un CIDR, que representa el intervalo IP que desea permitirlist. Ejemplo: 1.1.1.1/24
Todos los formatos excepto JSON (que se deben agregar por sí solos) se pueden combinar separando con una nueva línea.
Protección de contenido
La mayoría de las plataformas tienen varias formas de proteger las secuencias impidiendo el acceso a los visores no deseados. Microsoft eCDN reconoce esto y, por lo tanto, no cambia ningún mecanismo de protección de contenido existente.
Como sucedería sin Microsoft eCDN, cada usuario tiene que autenticarse en el servidor y solo si se autentica correctamente, el servidor enviará el archivo de manifiesto al visor, lo que a su vez comienza a solicitar segmentos para reproducir la secuencia.
A continuación se muestra una lista de los esquemas de protección más comunes:
Autenticación al iniciar la sesión
En este caso, cada sesión comienza con el servidor solicitando al visor sus credenciales. Si estas credenciales son válidas, el servidor envía el archivo de manifiesto al visor y el reproductor de vídeo comienza a solicitar segmentos y manifiestos adicionales desde el servidor HTTP. Microsoft eCDN no se inserta en este proceso de validación y el visor debe pasar a través de las mismas puertas de autenticación independientemente de si microsoft eCDN está implementado o no. Solo los espectadores autorizados para watch una secuencia específica pueden participar en el uso compartido de P2P para esa secuencia y solo lo comparten mientras realmente están viendo la secuencia.
Tokenización de URI de manifiesto
Microsoft eCDN también se adhiere a los mecanismos de tokenización de URI existentes que existen en el nivel de manifiesto.
Con Microsoft eCDN, todas las solicitudes de manifiesto se envían directamente al servidor HTTP, por lo que la validación se realiza con el back-end de la plataforma de la misma manera.
Tokenización con tiempo de URI
En este caso, la dirección URL del manifiesto tiene un token adicional, que codifica detalles sobre el agente de usuario del visor (dirección IP, tiempo de expiración, etc.). Un usuario malintencionado puede distribuir la dirección URL del manifiesto a visores no autorizados, pero esos visores no podrán acceder a la secuencia, ya que la dirección URL del manifiesto está tokenizada y el servidor HTTP rechaza cualquier intento de validación, ya sea debido a la dirección IP u otros errores de coincidencia del agente de usuario o debido a la expiración del tiempo. Con Microsoft eCDN, todas las solicitudes de manifiesto se envían directamente al servidor HTTP, por lo que la validación no se puede poner en peligro.
Cifrado
Con el cifrado de contenido, los usuarios deben pasar por la autenticación existente en su lugar y acceder a la clave de descifrado. Microsoft eCDN no tiene acceso a la clave de descifrado y no cambia la forma en que se distribuye y protege. Microsoft eCDN es independiente de los distintos esquemas de protección de contenido y estándares de soporte técnico como AES-128.
Por ejemplo, dado un flujo HLS protegido con el cifrado AES-128, los visores no autorizados no podrán watch la secuencia porque no tendrán acceso a la clave de descifrado.
La clave se puede enviar al usuario final de varias maneras: por ejemplo, a través del manifiesto, agrupada con la página o incluso solicitada dinámicamente con código personalizado.
Microsoft eCDN no se inserta en este proceso y la clave se entrega al reproductor de vídeo con el mismo mecanismo independientemente de si se implementa Microsoft eCDN o no.
DRM
El caso de uso de DRM es similar al caso de uso del cifrado: la única diferencia es que la licencia y las claves se distribuyen por el mecanismo DRM en lugar de por el emisor. También aquí, Microsoft eCDN no interfiere con la distribución de la licencia o las claves y, por lo tanto, no las pone en peligro.