Freigeben über

Inhaltsschutz mit dynamischer Verschlüsselung und Schlüsselübermittlung

  • Artikel

Media Services-Logo v3

Warnung

Azure Media Services wird am 30. Juni 2024 eingestellt. Weitere Informationen finden Sie im Leitfaden zur Einstellung von AMS.

Verwenden Sie Azure Media Services, um Ihre Medien ab dem Zeitpunkt zu schützen, zu dem sie Ihren Computer verlassen, bis hin zur Speicherung, Verarbeitung und Übermittlung. Mit Media Services können Sie Ihre zu übermittelnden Live- und On-Demand-Inhalte dynamisch mit Advanced Encryption Standard (AES-128) oder einem der drei wichtigsten DRM-Systeme verschlüsseln: Microsoft PlayReady, Google Widevine und Apple FairPlay.

FairPlay Streaming ist eine Apple-Technologie, die nur für Videos verfügbar ist, die über HTTP Live Streaming (HLS) auf iOS-Geräten, in Apple TV und in Safari auf macOS übertragen werden. Media Services bietet auch einen Dienst für die Übermittlung von AES-Schlüsseln und DRM-Lizenzen (PlayReady, Widevine und FairPlay) an autorisierte Clients. Inhalt, der mit einem unverschlüsselten AES-Schlüssel verschlüsselt und per HTTPS gesendet wird, bleibt verschlüsselt, bis er den Client erreicht.

In Media Services v3 ist dem Streaminglocator ein Inhaltsschlüssel zugeordnet (siehe dieses Beispiel). Bei Verwendung des Media Services-Schlüsselübermittlungsdiensts kann der Inhaltsschlüssel durch Azure Media Services generiert werden. Sie sollten den Inhaltsschlüssel selbst generieren, wenn Sie Ihren eigenen Schlüsselbereitstellungsdienst verwenden oder ein Hochverfügbarkeitsszenario, sodass Sie denselben Inhaltsschlüssel in zwei Rechenzentren benötigen.

Wenn ein Player einen Stream anfordert, verwendet Media Services den angegebenen Schlüssel, um den Inhalt dynamisch mit einem unverschlüsselten AES-Schlüssel oder per DRM-Verschlüsselung zu verschlüsseln. Um den Stream zu entschlüsseln, fordert der Player den Schlüssel vom Media Services-Schlüsselübermittlungsdienst oder dem von Ihnen angegebenen Schlüsselübermittlungsdienst an. Um zu entscheiden, ob der Benutzer berechtigt ist, den Schlüssel zu erhalten, wertet der Dienst die Richtlinie für Inhaltsschlüssel aus, die Sie für den Schlüssel angegeben haben.

Inhaltsschutzsystem

Zum Konfigurieren von Autorisierungs- und Authentifizierungsrichtlinien für Ihre Lizenzen und Schlüssel können Sie die REST-API oder eine Media Services-Clientbibliothek verwenden.

Widevine ist in der Region „GovCloud“ nicht verfügbar.

Hinweis

Medienservices erzwingen TLS 1.2 für alle Anforderungen an KeyDelivery-, RESTv2-, Streamingendpunkt- und Liveereignis-Streamingursprünge. Konten mit vorhandener Nutzung von TLS 1.0 oder 1.1 werden von dieser Erzwingung ausgenommen. Wenn Sie TLS 1.2 für alle Ihre Anforderungen an diese Medienservices-Endpunkte erzwingen möchten, wenden Sie sich bitte an den AMS-Support.

Browser, die DRM-Clients unterstützen

Folgende DRM-Clients werden von gängigen Browsern unterstützt:

Browser Verschlüsselung
Chrome Widevine
Microsoft Edge, Internet Explorer 11 PlayReady
Firefox Widevine
Opera Widevine
Safari FairPlay

Steuern des Inhaltszugriffs

Sie können steuern, wer Zugriff auf Ihre Inhalte hat, indem Sie die Richtlinie für Inhaltsschlüssel konfigurieren. Media Services unterstützt mehrere Möglichkeiten zur Autorisierung von Benutzern, die Schlüssel anfordern. Der Client (Player) muss die Richtlinie erfüllen, bevor der Schlüssel an den Client übermittelt werden kann. Die Richtlinie für Inhaltsschlüssel kann eine offene oder eine Tokeneinschränkung enthalten.

Eine Richtlinie für Inhaltsschlüssel mit offener Einschränkung kann verwendet werden, wenn Sie eine Lizenz für Personen ohne Autorisierung ausgeben möchten. Beispielsweise wenn Ihr Umsatz AD-basiert und nicht abonnementbasiert ist.

Bei einer Richtlinie für Inhaltsschlüssel mit Tokeneinschränkung wird der Inhaltsschlüssel nur an einen Client gesendet, der in der Lizenz-/Schlüsselanforderung ein gültiges JWT-Token oder ein einfaches Webtoken (Simple Web Token, SWT) präsentiert. Dieses Token muss von einem Sicherheitstokendienst (STS) ausgestellt werden.

Verwenden von Azure AD als Sicherheitstokendienst

Als Sicherheitstokendienst können Sie Azure AD verwenden. Der Dienst muss für die Erstellung eines mit dem angegebenen Schlüssel signierten Tokens und die Ausstellungsansprüche konfiguriert sein, die Sie in der Konfiguration der Tokeneinschränkung angegeben haben. Der Media Services-Dienst zur Lizenz-/Schlüsselbereitstellung gibt die angeforderte Lizenz bzw. den angeforderten Schlüssel an den Client zurück, wenn die beiden folgenden Bedingungen erfüllt sind:

  • Das Token ist gültig.
  • Die Ansprüche im Token entsprechen denen, die für die Lizenz oder den Schlüssel konfiguriert sind.

Bei der Konfiguration der Richtlinie mit Tokeneinschränkung müssen die Parameter für den primären Verifizierungsschlüssel (primary verification key), den Aussteller (issuer) und die Zielgruppe (audience) angegeben werden. Der primäre Verifizierungsschlüssel enthält den Schlüssel, mit dem das Token signiert wurde. Der Aussteller ist der Sicherheitstokendienst, der das Token ausstellt. „Audience“ (manchmal auch Scope) beschreibt den Verwendungszweck des Tokens oder die Ressource, auf die durch das Token Zugriff gewährt wird. Der Lizenz-/Schlüsselbereitstellungsdienst von Media Services überprüft, ob diese Werte im Token mit den Werten in der Vorlage übereinstimmen.

Verhindern der Tokenwiedergabe

Mit dem Feature Tokenreplay Prevention können Sie ein Limit festlegen, wie oft dasselbe Token zum Anfordern eines Schlüssels oder einer Lizenz verwendet werden kann. Sie können dem Token einen Anspruch vom Typ urn:microsoft:azure:mediaservices:maxuses hinzufügen, wobei der Wert die Häufigkeit ist, mit der das Token zum Abrufen einer Lizenz oder eines Schlüssels verwendet werden kann. Bei allen nachfolgenden Anforderungen mit demselben Token für die Schlüsselbereitstellung wird eine nicht autorisierte Antwort zurückgegeben.

Überlegungen

  • Sie müssen die Kontrolle über die Tokengenerierung haben. Der Anspruch muss in das Token selbst eingefügt werden.
  • Bei Verwendung dieser Funktion werden Anforderungen mit Token, deren Ablaufzeit mehr als eine Stunde vor dem Zeitpunkt liegt, zu dem die Anforderung empfangen wird, werden mit der Antwort „nicht autorisiert“ abgelehnt.
  • Token werden durch ihre Signatur eindeutig identifiziert. Jede Änderung an der Nutzlast (z. B. eine Aktualisierung der Ablaufzeit oder des Anspruchs) ändert die Signatur des Tokens, und es zählt als ein neues Token, das bei der Schlüsselbereitstellung zuvor noch nicht aufgetreten ist.
  • Die Wiedergabe schlägt fehl, wenn das Token den maxuses Wert überschritten hat.
  • Die Lösung sollte für alle vorhandenen geschützten Inhalte verwendet werden können (nur das ausgegebene Token muss geändert werden).
  • Die Lösung sollte sowohl JWT als auch SWT unterstützen.

Verwenden eines benutzerdefinierten Sicherheitstokendienst

Möglicherweise entscheiden Sie sich auch für einen benutzerdefinierten Sicherheitstokendienst. Dies kann u.a. folgende Gründe haben:

  • Ihr Identitätsanbieter (IDP) unterstützt Azure AD nicht als Sicherheitstokendienst.

  • Sie benötigen eine flexiblere oder strengere Kontrolle bei der Integration des Sicherheitstokendiensts in das Abrechnungssystem Ihres Abonnenten.

    Beispielsweise kann ein OTT-Dienstanbieter mehrere Abonnentenpakete (z. B. „Premium“, „Standard“ und „Sport“) anbieten. Der Programmanbieter möchte die Ansprüche in einem Token mit dem Paket eines Abonnenten abgleichen, sodass nur die Inhalte in einem bestimmten Paket zur Verfügung gestellt werden. In diesem Fall bietet ein benutzerdefinierter STS die erforderliche Flexibilität und Kontrolle.

  • Sie möchten benutzerdefinierte Ansprüche in das Token einfügen, um zwischen verschiedenen ContentKeyPolicyOptions mit unterschiedlichen DRM-Lizenzparametern – beispielsweise einer Abonnement- oder Mietlizenz – auszuwählen.

  • Einfügen eines Anspruchs, der den Bezeichner des Inhaltsschlüssels darstellt, auf den das Token den Zugriff ermöglicht.

Wenn Sie einen benutzerdefinierten Sicherheitstokendienst verwenden, müssen Sie zwei Änderungen vornehmen:

  • Bei der Konfiguration des Lizenzbereitstellungsdiensts für ein Medienobjekt müssen Sie anstelle des aktuellen Schlüssels aus Azure AD den Sicherheitsschlüssel angeben, der vom benutzerdefinierten Sicherheitstokendienst zur Überprüfung verwendet wird.
  • Wenn ein JWT generiert wird, wird anstelle des privaten Schlüssels des aktuellen X.509-Zertifikats in Azure AD ein Sicherheitsschlüssel angegeben.

Es gibt zwei Arten von Sicherheitsschlüsseln:

  • Symmetrischer Schlüssel: Um ein JWT zu generieren und zu überprüfen, wird ein und derselbe Schlüssel verwendet.
  • Asymmetrischer Schlüssel: Ein Paar aus öffentlichem und privatem Schlüssel in einem X.509-Zertifikat wird mit einem privaten Schlüssel verwendet, um ein JWT zu verschlüsseln und zu generieren. Das gleiche Paar wird mit dem öffentlichen Schlüssel verwendet, um das Token zu überprüfen.

Hinweis

Bei Verwendung von .NET Framework/C# als Entwicklungsplattform muss das X.509-Zertifikat für einen asymmetrischen Sicherheitsschlüssel eine Schlüssellänge von mindestens 2048 aufweisen. Diese Schlüssellänge ist eine Voraussetzung für die System.IdentityModel.Tokens.X509AsymmetricSecurityKey-Klasse in .NET Framework. Andernfalls wird die folgende Ausnahme ausgelöst: IDX10630: „System.IdentityModel.Tokens.X509AsymmetricSecurityKey“ für die Signierung darf nicht kleiner als 2.048 Bits sein.

Verwenden eines anderen Lizenz-/Schlüsselbereitstellungsdiensts als Media Services

Wenn Sie einen anderen Lizenz-/Schlüsselbereitstellungsdienst verwenden möchten, können Sie die Richtlinienvorlagen für Schlüssel entsprechend anpassen.

How-Tos, Tutorials und Beispiele

Das .NET Digital Rights Management-Beispiel zeigt, wie Sie ein Multi-DRM-System mit Media Services v3 mithilfe von .NET implementieren.

Für Node.JS und Python sind weitere Beispiele zum Inhaltsschutz verfügbar:

Node.JS Python BESCHREIBUNG
Node.JS: Hochladen und Streamen von HLS und DASH mit PlayReady und Widevine DRM Python: Hochladen und Streamen von HLS und DASH mit PlayReady und Widevine DRM Zeigt, wie Sie mithilfe von Widevine und PlayReady DRM codieren und streamen.
Node.JS: Grundlegender Inhaltsschutz und Streaming mit Playready DRM Python: Grundlegender Inhaltsschutz und Streaming mit Playready DRM Zeigt, wie Sie mit PlayReady DRM codieren und streamen.
Node.JS: Grundlegender Inhaltsschutz und Streaming mit Widevine DRM Python: Grundlegender Inhaltsschutz und Streaming mit Widevine DRM Zeigt, wie Sie mit Widevine DRM codieren und streamen.

Anfordern von Hilfe und Support

Sie können Media Services mit Fragen kontaktieren oder unsere Updates mit einer der folgenden Methoden verfolgen: