Sicherheitsübersicht
Microsoft eCDN ist ein M365-kompatibler Dienst. Dies bedeutet, dass alle sicherheitsstandards eingehalten werden, die von jedem anderen M365-Dienst verwaltet werden.
In diesem Dokument werden mehrere Artikel vorgestellt, die sich speziell auf die Sicherheit beziehen, da sie für die Übermittlung von Videostreaming gilt.
Microsoft eCDN ist eine Hybridlösung, was bedeutet, dass Microsoft eCDN in Kombination mit einem herkömmlichen HTTP-Server verwendet wird, während die bereits vorhandene Sicherheitsinfrastruktur (Token, Schlüssel, Cookies usw.) genutzt wird.
In Bezug auf die Kommunikation gibt es zwei Standard Kommunikationskanäle:
Zwischen Gleichaltrigen; Peers sind über den WebRTC-Datenkanal miteinander verbunden. Dabei handelt es sich um einen sicheren Tunnel, der das SCTP-Protokoll über DTLS-Verschlüsselung verwendet.
Zwischen jedem Viewer und dem Microsoft eCDN-Back-End über eine sichere WebSocket-Verbindung, die TLS-Verschlüsselung verwendet.
Beide Kanäle verwenden Netzwerksicherheitsprotokolle nach Branchenstandard, sodass weder die zwischen zwei Viewern gesendeten Daten noch die zwischen jedem Viewer und dem Back-End des Diensts gesendeten Metadaten kompromittiert werden können.
Darüber hinaus verfügt der Dienst über zusätzliche Sicherheitsfeatures, die basierend auf individuellen Anforderungen aktiviert werden können, die unten erläutert werden.
Viewer-Authentifizierung
Normalerweise kann jeder Viewer eine Verbindung mit dem Microsoft eCDN-Back-End herstellen und am P2P-Netzwerk teilnehmen. Dies ist in den meisten Anwendungsfällen akzeptabel, aber einige Kunden ziehen es vor, einzuschränken, welche Zuschauer eine Verbindung mit dem Dienst herstellen können.
In diesen Fällen kann das Back-End Viewer direkt authentifizieren, zusätzlich zu allen Authentifizierungsmechanismen, die möglicherweise bereits aufseiten des Inhaltsanbieters vorhanden sind. Die von Microsoft eCDN eingerichteten Authentifizierungsmechanismen verhindern, dass nicht autorisierte Benutzer auf Inhalte und metadaten zugreifen, die im Peer-to-Peer-Netzwerk vorhanden sind.
Liste zugelassener Domänen
Die schnellste und einfachste Möglichkeit, die meisten unerwünschten Zuschauer daran zu hindern, am Peering teilzunehmen, besteht darin, bestimmte Domänen explizit auf die Zulassungsliste zu setzen, von denen Aus-Benutzer eine Verbindung mit dem Back-End des Diensts herstellen können. Dies bedeutet, dass Viewer, die versuchen, eine Verbindung mit dem Dienst von anderen Domänen herzustellen, die keine Zulassungsliste enthalten, blockiert werden.
Schritt-für-Schritt-Anleitung:
Wechseln Sie im Verwaltungskonsole zur Konfigurationsseite für Drittanbieterplattformen.
Fügen Sie Ihre Domänen (die Domänen, in die die Dienstskripts geladen werden) im Feld "Website-Zulassungsliste" hinzu, wie unten gezeigt.
Das ist alles. Jeder Viewer, der versucht, eine Verbindung mit dem Dienst mit Ihrer Mandanten-ID aus einer nicht aufgeführten Domäne herzustellen, wird blockiert.
Liste der zulässigen Endbenutzer-IP-Adressen
Ein weiteres Mittel, mit dem Administratoren unerwünschte Zuschauer daran hindern können, am Peering teilzunehmen, besteht darin, nur den Zugriff auf den Dienst aus einer vordefinierten Liste öffentlicher IP-Adressen zuzulassen. Dies ähnelt dem oben genannten Feature "Domain Allowlisting", aber dieses Mal lassen wir die öffentlichen IP-Adressen der Zuschauer auf.
Schritt-für-Schritt-Anleitung:
Wechseln Sie im Verwaltungskonsole zur Seite Sicherheitskonfiguration.
Fügen Sie die gewünschten öffentlichen IP-Adressen oder IP-Adressbereiche im Feld "Liste zugelassener IP-Adressen" für Endbenutzer in einem der unterstützten Formate hinzu, wie unten gezeigt.
Das ist alles. Jeder Viewer, der versucht, eine Verbindung mit dem Dienst mit Ihrer Mandanten-ID mit einer nicht zulässigen IP-Adresse herzustellen, wird blockiert.
Unterstützte Formate:
Einzelne IP-Adresse : Geben Sie jede IP-Adresse in einer neuen Zeile ein, oder fügen Sie sie einzeln hinzu, indem Sie nacheinander auf die Schaltfläche "IP-Adressen hinzufügen" klicken. Beispiel: 1.1.1.1
CIDR : Geben Sie einen CIDR-Wert ein, der den IP-Adressbereich darstellt, den Sie auf die Zulassungsliste setzen möchten. Beispiel: 1.1.1.1/24
Alle Formate mit Ausnahme von JSON (das selbst hinzugefügt werden muss) können gemischt und abgeglichen werden, indem sie durch eine neue Zeile getrennt werden.
Inhaltsschutz
Die meisten Plattformen haben mehrere Möglichkeiten, Datenströme zu schützen, indem sie den Zugriff auf unerwünschte Viewer verhindern. Microsoft eCDN erkennt dies und ändert daher keine vorhandenen Mechanismen zum Schutz von Inhalten.
Wie ohne Microsoft eCDN muss sich jeder Benutzer beim Server authentifizieren, und nur bei erfolgreicher Authentifizierung sendet der Server die Manifestdatei an den Viewer, der wiederum beginnt, Segmente zur Wiedergabe des Streams anzufordern.
Im Folgenden finden Sie eine Liste der am häufigsten verwendeten Schutzsysteme:
Authentifizierung beim Sitzungsstart
In diesem Fall beginnt jede Sitzung damit, dass der Server den Viewer nach seinen Anmeldeinformationen fragt. Wenn diese Anmeldeinformationen gültig sind, sendet der Server die Manifestdatei an den Viewer, und der Videoplayer beginnt, Segmente und zusätzliche Manifeste vom HTTP-Server anzufordern. Microsoft eCDN fügt sich nicht in diesen Überprüfungsprozess ein, und der Viewer muss die gleichen Authentifizierungsgates durchlaufen, unabhängig davon, ob Microsoft eCDN bereitgestellt wird. Nur Zuschauer, die berechtigt sind, einen bestimmten Stream zu watch, können an der P2P-Freigabe für diesen Stream teilnehmen, und sie teilen nur, während sie den Stream tatsächlich beobachten.
Manifest-URI-Tokenisierung
Microsoft eCDN hält auch alle vorhandenen URI-Tokenisierungsmechanismen ein, die auf Manifestebene vorhanden sind.
Mit Microsoft eCDN werden alle Manifestanforderungen direkt an den HTTP-Server gesendet, sodass die Validierung mit dem Plattform-Back-End auf die gleiche Weise erfolgt.
URI-Zeittokenisierung
In diesem Fall verfügt die Manifest-URL über ein zusätzliches Token, das Details zum Benutzer-Agent des Viewers (IP-Adresse, Ablaufzeit usw.) codiert. Ein böswilliger Benutzer kann die Manifest-URL an nicht autorisierte Viewer verteilen, aber diese Viewer können nicht auf den Datenstrom zugreifen, da die Manifest-URL tokenisiert wird und der HTTP-Server alle Überprüfungsversuche ablehnt – entweder aufgrund der IP-Adresse oder anderer Nichtübereinstimmungen des Benutzer-Agents oder aufgrund eines Zeitablaufs. Mit Microsoft eCDN werden alle Manifestanforderungen direkt an den HTTP-Server gesendet, sodass die Überprüfung nicht kompromittiert werden kann.
Verschlüsselung
Bei der Inhaltsverschlüsselung müssen Benutzer die vorhandene Authentifizierung durchlaufen und auf den Entschlüsselungsschlüssel zugreifen. Microsoft eCDN hat keinen Zugriff auf den Entschlüsselungsschlüssel und ändert nicht die Art und Weise, wie er verteilt und geschützt wird. Microsoft eCDN ist unabhängig von den verschiedenen Inhaltsschutzprogrammen und Supportstandards wie AES-128.
Wenn beispielsweise ein HLS-Stream mit AES-128-Verschlüsselung geschützt ist, können nicht autorisierte Viewer den Datenstrom nicht watch, da sie keinen Zugriff auf den Entschlüsselungsschlüssel haben.
Der Schlüssel kann auf vielfältige Weise an den Endbenutzer gesendet werden – z. B. über das Manifest, gebündelt mit der Seite oder sogar dynamisch mit benutzerdefiniertem Code.
Microsoft eCDN fügt sich nicht selbst in diesen Prozess ein, und der Schlüssel wird mit demselben Mechanismus an den Videoplayer übermittelt, unabhängig davon, ob Microsoft eCDN bereitgestellt wird oder nicht.
DRM
Der DRM-Anwendungsfall ähnelt dem Verschlüsselungsanwendungsfall. Der einzige Unterschied besteht darin, dass die Lizenz und die Schlüssel vom DRM-Mechanismus statt vom Sender verteilt werden. Auch hier stört Microsoft eCDN nicht die Verteilung der Lizenz oder der Schlüssel und gefährdet sie daher nicht.