Vue d’ensemble de la sécurité
Microsoft eCDN est un service conforme À M365. Cela signifie qu’il suit les mêmes normes de sécurité gérées par tout autre service M365.
Ce document met en évidence plusieurs articles spécifiques à la sécurité, car il s’applique à la diffusion en continu de vidéos.
Microsoft eCDN est une solution hybride, ce qui signifie que Microsoft eCDN est utilisé en combinaison avec un serveur HTTP traditionnel, tout en tirant parti de l’infrastructure de sécurité existante (jetons, clés, cookies, etc.) qui est déjà en place.
En termes de communication, il existe deux canaux de communication main :
Entre pairs ; Les pairs sont connectés les uns aux autres via le canal de données WebRTC, qui est un tunnel sécurisé qui utilise le protocole SCTP sur le chiffrement DTLS.
Entre chaque visionneuse et le back-end Microsoft eCDN via une connexion WebSocket sécurisée qui utilise le chiffrement TLS.
Les deux canaux utilisent des protocoles de sécurité réseau standard de sorte que ni les données envoyées entre deux visionneuses, ni les métadonnées envoyées entre chaque visionneuse et le back-end du service ne peuvent être compromises.
En plus de ce qui précède, le service dispose de fonctionnalités de sécurité supplémentaires qui peuvent être activées, en fonction des exigences individuelles, qui sont expliquées ci-dessous.
Authentification de la visionneuse
Normalement, n’importe quelle visionneuse peut se connecter au back-end Microsoft eCDN et participer au réseau P2P. Cela est acceptable dans la plupart des cas d’usage, mais certains clients peuvent préférer limiter les utilisateurs qui peuvent se connecter au service.
Dans ce cas, le back-end peut authentifier directement les visionneuses, en plus des mécanismes d’authentification qui peuvent déjà exister côté fournisseur de contenu. Les mécanismes d’authentification que Microsoft eCDN a mis en place empêchent les utilisateurs non autorisés d’accéder au contenu et aux métadonnées qui existent sur le réseau d’égal à égal.
Liste verte des domaines
Le moyen le plus rapide et le plus simple d’empêcher la plupart des téléspectateurs indésirables de participer au peering consiste à autoriser explicitement la liste de domaines spécifiques à partir desquels les utilisateurs peuvent se connecter au back-end du service. Cela signifie que les visionneuses qui tentent de se connecter au service à partir d’autres domaines non autorisés sont bloquées.
Guide pas à pas :
Accédez à la page de configuration des plateformes tierces dans le console de gestion.
Ajoutez vos domaines (ceux où les scripts de service sont chargés) dans la zone « Liste verte des sites web », comme indiqué ci-dessous.
Voilà ! Toute visionneuse qui tente de se connecter au service avec votre ID de locataire à partir d’un domaine non répertorié sera bloquée.
Liste verte de l’adresse IP de l’utilisateur final
Un autre moyen par lequel les administrateurs peuvent empêcher les utilisateurs indésirables de participer au peering consiste à autoriser uniquement l’accès au service à partir d’une liste prédéfinie d’adresses IP publiques. Ceci est similaire à la fonctionnalité de « liste d’autorisation de domaine » ci-dessus, mais cette fois, nous autorisons les adresses IP publiques des téléspectateurs.
Guide pas à pas :
Accédez à la page Configuration de la sécurité dans le console de gestion.
Ajoutez les adresses IP publiques ou les plages d’adresses IP publiques souhaitées dans la zone « Liste d’adresses IP autorisées des utilisateurs finaux » dans l’un des formats pris en charge, comme indiqué ci-dessous.
Voilà ! Toute visionneuse qui tente de se connecter au service avec votre ID de locataire avec une adresse IP qui n’est pas autorisée est bloquée.
Formats pris en charge :
Adresse IP unique : entrez chaque adresse IP dans une nouvelle ligne ou ajoutez-les une par une, en cliquant sur le bouton « Ajouter des adresses IP » après chacune d’elles. Exemple : 1.1.1.1
CIDR : entrez un CIDR, qui représente la plage d’adresses IP que vous souhaitez autoriser. Exemple : 1.1.1.1/24
Tous les formats, à l’exception de JSON (qui doit être ajouté de manière autonome), peuvent être mélangés et mis en correspondance en les séparant par une nouvelle ligne.
Protection du contenu
La plupart des plateformes ont plusieurs façons de protéger les flux en empêchant l’accès aux visionneuses indésirables. Microsoft eCDN le reconnaît et ne modifie donc pas les mécanismes de protection de contenu existants.
Comme cela se produit sans Microsoft eCDN, chaque utilisateur doit s’authentifier auprès du serveur, et ce n’est qu’en cas d’authentification réussie que le serveur envoie le fichier manifeste à la visionneuse, qui à son tour commence à demander des segments pour lire le flux.
Voici une liste des schémas de protection les plus courants :
Authentification au démarrage de session
Dans ce cas, chaque session commence par le serveur demandant ses informations d’identification à la visionneuse. Si ces informations d’identification sont valides, le serveur envoie le fichier manifeste à la visionneuse, et le lecteur vidéo commence à demander des segments et des manifestes supplémentaires auprès du serveur HTTP. Microsoft eCDN ne s’insère pas dans ce processus de validation, et la visionneuse doit passer par les mêmes portes d’authentification, que Microsoft eCDN soit déployé ou non. Seuls les téléspectateurs autorisés à watch un flux spécifique peuvent participer au partage P2P pour ce flux, et ils partagent uniquement pendant qu’ils regardent réellement le flux.
Tokenisation de l’URI de manifeste
Microsoft eCDN adhère également à tous les mécanismes de tokenisation d’URI existants qui existent au niveau du manifeste.
Avec Microsoft eCDN, toutes les demandes de manifeste sont envoyées directement au serveur HTTP. La validation a donc lieu avec le serveur principal de la plateforme de la même manière.
Tokenisation chronométrée de l’URI
Dans ce cas, l’URL du manifeste comporte un jeton supplémentaire, qui encode les détails sur l’agent utilisateur de la visionneuse (adresse IP, heure d’expiration, etc.). Un utilisateur malveillant peut distribuer l’URL du manifeste à des visionneuses non autorisées, mais ces visionneuses ne pourront pas accéder au flux, car l’URL du manifeste est tokenisée et le serveur HTTP rejette toute tentative de validation, soit en raison de l’incompatibilité de l’adresse IP ou d’autres agents utilisateur, soit en raison de l’expiration du délai. Avec Microsoft eCDN, toutes les demandes de manifeste sont envoyées directement au serveur HTTP afin que la validation ne puisse pas être compromise.
Chiffrement
Avec le chiffrement de contenu, les utilisateurs doivent passer par l’authentification existante en place et accéder à la clé de déchiffrement. Microsoft eCDN n’a pas accès à la clé de déchiffrement et ne modifie pas la façon dont elle est distribuée et protégée. Microsoft eCDN est indépendant des différents schémas de protection du contenu et prend en charge les normes telles que AES-128.
Par exemple, avec un flux HLS protégé par le chiffrement AES-128, les utilisateurs non autorisés ne pourront pas watch le flux, car ils n’auront pas accès à la clé de déchiffrement.
La clé peut être envoyée à l’utilisateur final de nombreuses façons : par exemple, via le manifeste, groupé avec la page ou même demandé dynamiquement avec du code personnalisé.
Microsoft eCDN ne s’insère pas dans ce processus, et la clé est remise au lecteur vidéo à l’aide du même mécanisme, que Microsoft eCDN soit déployé ou non.
DRM
Le cas d’utilisation drm ressemble au cas d’usage de chiffrement . La seule différence est que la licence et les clés sont distribuées par le mécanisme DRM au lieu de par le diffuseur. Ici aussi, Microsoft eCDN n’interfère pas avec la distribution de la licence ou des clés et ne les compromet donc pas.