Panoramica della sicurezza
Microsoft eCDN è un servizio conforme a M365. Ciò significa che segue tutti gli stessi standard di sicurezza gestiti da qualsiasi altro servizio M365.
Questo documento evidenzia diversi articoli specifici per la sicurezza in quanto si applica al recapito di streaming video.
Microsoft eCDN è una soluzione ibrida, il che significa che Microsoft eCDN viene usato in combinazione con un server HTTP tradizionale, sfruttando al tempo stesso l'infrastruttura di sicurezza esistente (token, chiavi, cookie e così via) già esistente.
In termini di comunicazione, esistono due principali canali di comunicazione:
Tra peer; I peer sono connessi tra loro tramite il canale dati WebRTC, ovvero un tunnel sicuro che usa il protocollo SCTP tramite la crittografia DTLS.
Tra ogni visualizzatore e il back-end Microsoft eCDN tramite una connessione WebSocket sicura che usa la crittografia TLS.
Entrambi i canali usano protocolli di sicurezza di rete standard del settore, quindi né i dati inviati tra due visualizzatori né i metadati inviati tra ogni visualizzatore e il back-end del servizio possono essere compromessi.
Oltre a quanto sopra, il servizio dispone di funzionalità di sicurezza aggiuntive che possono essere abilitate, in base ai singoli requisiti, illustrate di seguito.
Autenticazione del visualizzatore
In genere, qualsiasi visualizzatore può connettersi al back-end Microsoft eCDN e partecipare alla rete P2P. Ciò è accettabile nella maggior parte dei casi d'uso, ma alcuni clienti potrebbero preferire limitare i visualizzatori che possono connettersi al servizio.
In questi casi, il back-end può autenticare direttamente i visualizzatori, oltre a qualsiasi meccanismo di autenticazione già esistente sul lato provider di contenuto. I meccanismi di autenticazione di Microsoft eCDN impediscono ai visualizzatori non autorizzati di accedere al contenuto e agli eventuali metadati presenti nella rete peer-to-peer.
Elenco di domini consentiti
Il modo più rapido e semplice per impedire alla maggior parte degli utenti indesiderati di partecipare al peering consiste nell'inserimento esplicito di domini specifici da cui i visualizzatori possono connettersi al back-end del servizio. Ciò significa che i visualizzatori che tentano di connettersi al servizio da altri domini non consentiti vengono bloccati.
Guida dettagliata:
Passare alla pagina di configurazione di Piattaforme di terze parti nella console di gestione.
Aggiungere i domini (quelli in cui vengono caricati gli script del servizio) nella casella "Elenco siti Web consentiti", come illustrato di seguito.
È tutto. Qualsiasi visualizzatore che tenta di connettersi al servizio con l'ID tenant da un dominio non elencato verrà bloccato.
Elenco di indirizzi IP consentiti per l'utente finale
Un altro mezzo con cui gli amministratori possono impedire ai visualizzatori indesiderati di partecipare al peering consiste nel consentire l'accesso al servizio solo da un elenco predefinito di INDIRIZZI IP pubblici. Questa operazione è simile alla funzionalità "domain allowlisting" precedente, ma questa volta sono consentiti gli INDIRIZZI IP pubblici dei visualizzatori.
Guida dettagliata:
Passare alla pagina Configurazione della sicurezza nella console di gestione.
Aggiungere gli indirizzi IP pubblici o gli intervalli IP desiderati nella casella "Elenco indirizzi IP consentiti per gli utenti finali" in uno dei formati supportati, come illustrato di seguito.
È tutto. Qualsiasi visualizzatore che tenta di connettersi al servizio con l'ID tenant con un INDIRIZZO IP non consentito è bloccato.
Formati supportati:
IP singolo : immettere ogni INDIRIZZO IP in una nuova riga o aggiungerli uno alla volta, facendo clic sul pulsante "Aggiungi INDIRIZZI IP" dopo ognuno di essi. Esempio: 1.1.1.1
CIDR : immettere un CIDR, che rappresenta l'intervallo IP che si vuole consentire. Esempio: 1.1.1.1/24
Tutti i formati tranne JSON (che devono essere aggiunti autonomamente) possono essere combinati e abbinati separandoli con una nuova riga.
Protezione del contenuto
La maggior parte delle piattaforme ha diversi modi per proteggere i flussi impedendo l'accesso ai visualizzatori indesiderati. Microsoft eCDN riconosce questo aspetto e pertanto non modifica alcun meccanismo di protezione del contenuto esistente.
Come accade senza Microsoft eCDN, ogni utente deve autenticarsi sul server e solo se l'autenticazione viene eseguita correttamente il server invierà il file manifesto al visualizzatore, che a sua volta inizia a richiedere segmenti per riprodurre il flusso.
Di seguito è riportato un elenco degli schemi di protezione più comuni:
Autenticazione all'avvio della sessione
In questo caso, ogni sessione inizia con il server che richiede le credenziali al visualizzatore. Se queste credenziali sono valide, il server invia il file manifesto al visualizzatore e il lettore video inizia a richiedere segmenti e manifesti aggiuntivi dal server HTTP. Microsoft eCDN non si inserisce in questo processo di convalida e il visualizzatore deve passare attraverso gli stessi controlli di autenticazione indipendentemente dalla distribuzione o meno di Microsoft eCDN. Solo gli utenti autorizzati a watch un flusso specifico possono partecipare alla condivisione P2P per tale flusso e condividono solo mentre stanno effettivamente guardando il flusso.
Tokenizzazione URI manifesto
Microsoft eCDN rispetta anche tutti i meccanismi di tokenizzazione URI esistenti a livello di manifesto.
Con Microsoft eCDN, tutte le richieste di manifesto vengono inviate direttamente al server HTTP, quindi la convalida avviene con il back-end della piattaforma nello stesso modo.
Tokenizzazione con tempo URI
In questo caso, l'URL del manifesto ha un token aggiuntivo, che codifica i dettagli sull'agente utente del visualizzatore (indirizzo IP, ora di scadenza e così via). Un utente malintenzionato può distribuire l'URL del manifesto a visualizzatori non autorizzati, ma tali visualizzatori non saranno in grado di accedere al flusso poiché l'URL del manifesto è tokenizzato e il server HTTP rifiuta eventuali tentativi di convalida, a causa dell'indirizzo IP o di altri agenti utente non corrispondenti o a causa della scadenza del tempo. Con Microsoft eCDN, tutte le richieste di manifesto vengono inviate direttamente al server HTTP in modo che la convalida non possa essere compromessa.
Crittografia
Con la crittografia del contenuto, gli utenti devono eseguire l'autenticazione esistente sul posto e accedere alla chiave di decrittografia. Microsoft eCDN non ha accesso alla chiave di decrittografia e non cambia la modalità di distribuzione e protezione. Microsoft eCDN è indipendente dai diversi schemi di protezione dei contenuti e dagli standard di supporto, ad esempio AES-128.
Ad esempio, dato un flusso HLS protetto con crittografia AES-128, i visualizzatori non autorizzati non potranno watch il flusso perché non avranno accesso alla chiave di decrittografia.
La chiave può essere inviata all'utente finale in numerosi modi, ad esempio tramite il manifesto, in bundle con la pagina o anche richiesta dinamicamente con codice personalizzato.
Microsoft eCDN non si inserisce in questo processo e la chiave viene recapitata al lettore video usando lo stesso meccanismo indipendentemente dal fatto che Microsoft eCDN venga distribuito o meno.
DRM
Il caso d'uso DRM è simile al caso d'uso della crittografia: l'unica differenza è che la licenza e le chiavi vengono distribuite dal meccanismo DRM anziché dall'emittente. Anche in questo caso, Microsoft eCDN non interferisce con la distribuzione della licenza o delle chiavi e quindi non le compromette.