Innehållsskydd med dynamisk kryptering och nyckelleverans

Använd Azure Media Services för att skydda dina media från den tidpunkt då det lämnar datorn hela vägen genom lagring, bearbetning och leverans. Med Media Services kan du leverera ditt liveinnehåll och innehåll på begäran krypterat dynamiskt med Advanced Encryption Standard (AES-128) eller något av de tre stora DRM-systemen (Digital Rights Management): Microsoft PlayReady, Google Widevine och Apple FairPlay.

FairPlay Streaming är en Apple-teknik som endast är tillgänglig för video som överförs via HTTP Live Streaming (HLS) på iOS-enheter, i Apple TV och i Safari på macOS. Media Services tillhandahåller också en tjänst för att leverera AES-nycklar och DRM-licenser (PlayReady, Widevine och FairPlay) till auktoriserade klienter. Om innehållet krypteras med en AES-klartextnyckel och skickas via HTTPS är det inte klart förrän det når klienten.

I Media Services v3 är en innehållsnyckel associerad med positionerare för direktuppspelning (se det här exemplet). Om du använder Media Services-nyckelleveranstjänsten kan du låta Azure Media Services generera innehållsnyckeln åt dig. Innehållsnyckeln bör genereras själv om du använder en egen nyckelleveranstjänst, eller om du behöver hantera ett scenario med hög tillgänglighet där du behöver ha samma innehållsnyckel i två datacenter.

När en dataström begärs av en spelare använder Media Services den angivna nyckeln för att dynamiskt kryptera ditt innehåll med hjälp av AES-rensa nyckel eller DRM-kryptering. För att dekryptera strömmen begär spelaren nyckeln från Media Services-nyckelleveranstjänsten eller nyckelleveranstjänsten som du har angett. För att avgöra om användaren har behörighet att hämta nyckeln utvärderar tjänsten innehållsnyckelprincipen som du har angett för nyckeln.

Du kan använda REST-API:et eller ett Media Services-klientbibliotek för att konfigurera auktoriserings- och autentiseringsprinciper för dina licenser och nycklar.

Widevine är inte tillgängligt i GovCloud-regionen.

Webbläsare som stöder DRM-klienter

Vanliga webbläsare stöder följande DRM-klienter:

Kontrollera innehållsåtkomst

Du kan styra vem som har åtkomst till ditt innehåll genom att konfigurera innehållsnyckelprincipen. Media Services stöder flera olika sätt att auktorisera användare som begär nycklar. Klienten (spelaren) måste uppfylla principen innan nyckeln kan levereras till klienten. Innehållsnyckelprincipen kan ha begränsningar för öppna eller token .

En princip för öppen innehållsnyckel kan användas när du vill utfärda en licens till alla utan auktorisering. Om dina intäkter till exempel är annonsbaserade och inte prenumerationsbaserade.

Med en princip för tokenbegränsad innehållsnyckel skickas innehållsnyckeln endast till en klient som presenterar en giltig JWT-token eller en enkel webbtoken (SWT) i licens-/nyckelbegäran. Denna token måste utfärdas av en STS.

Använda Azure AD som sts

Du kan använda Azure AD som sts. Den måste konfigureras för att skapa en token som signerats med den angivna nyckeln och utfärda anspråk som du angav i konfigurationen för tokenbegränsning. Media Services-licensen/nyckelleveranstjänsten returnerar den begärda licensen eller nyckeln till klienten om båda dessa villkor finns:

• Token är giltig.
• Anspråken i token matchar de som har konfigurerats för licensen eller nyckeln.

När du konfigurerar den tokenbegränsade principen måste du ange den primära verifieringsnyckeln, utfärdaren och målgruppsparametrarna. Den primära verifieringsnyckeln innehåller nyckeln som token signerades med. Utfärdaren är den STS som utfärdar token. Målgruppen, som ibland kallas omfång, beskriver avsikten med token eller resursen som token auktoriserar åtkomst till. Media Services-licensen/nyckelleveranstjänsten verifierar att värdena i token matchar värdena i mallen.

Skydd mot tokenrepetion

Med funktionen Token Replay Prevention kan du ange en gräns för hur många gånger samma token kan användas för att begära en nyckel eller en licens. Du kan lägga till ett anspråk av typen urn:microsoft:azure:mediaservices:maxuses i token, där värdet är det antal gånger som token kan användas för att hämta en licens eller nyckel. Alla efterföljande begäranden med samma token till nyckelleverans returnerar ett obehörigt svar.

Överväganden

• Du måste ha kontroll över tokengenereringen. Anspråket måste placeras i själva token.
• När du använder den här funktionen avvisas begäranden med token vars förfallotid är mer än en timme från den tidpunkt då begäran tas emot med ett obehörigt svar.
• Token identifieras unikt med deras signatur. Alla ändringar av nyttolasten (till exempel uppdatering till förfallotiden eller anspråket) ändrar signaturen för token och räknas som en ny token som nyckelleveransen inte har stött på tidigare.
• Uppspelningen misslyckas om token har överskridit maxuses värdet.
• Den kan användas för allt befintligt skyddat innehåll (endast den token som utfärdas behöver ändras).
• Det fungerar med både JWT och SWT.

Använda en anpassad STS

Du kan välja att använda en anpassad STS för att tillhandahålla token. Orsaker är:

• Din identitetsprovider (IDP) stöder inte STS.

• Du kan behöva mer flexibel eller strängare kontroll för att integrera STS med ditt prenumerationsfaktureringssystem.

  En OTT-tjänstoperatör kan till exempel erbjuda flera prenumerationspaket, till exempel premium, basic och sport. Operatören kanske vill matcha anspråken i en token med en prenumerants paket så att endast innehållet i ett specifikt paket blir tillgängligt. I det här fallet ger en anpassad STS den flexibilitet och kontroll som krävs.

• Om du vill inkludera anpassade anspråk i token för att välja mellan olika ContentKeyPolicyOptions med olika DRM-licensparametrar, till exempel en prenumerationslicens jämfört med en hyreslicens.

• Inkludera ett anspråk som representerar innehållsnyckelidentifieraren för nyckeln som token beviljar åtkomst till.

När du använder en anpassad STS måste två ändringar göras:

• När du konfigurerar en licensleveranstjänst för en tillgång måste du ange den säkerhetsnyckel som används för verifiering av den anpassade STS i stället för den aktuella nyckeln från Azure AD.
• När en JTW-token genereras anges en säkerhetsnyckel i stället för den privata nyckeln för det aktuella X509-certifikatet i Azure AD.

Det finns två typer av säkerhetsnycklar:

• Symmetrisk nyckel: Samma nyckel används för att generera och verifiera en JWT.
• Asymmetrisk nyckel: Ett offentligt-privat nyckelpar i ett X509-certifikat används med en privat nyckel för att kryptera/generera en JWT och med den offentliga nyckeln för att verifiera token.

Använda en annan licens-/nyckelleveranstjänst än Media Services

Du kan redigera nyckelprincipmallar om du vill använda en annan licens-/nyckelleveranstjänst.

Instruktioner, självstudier och exempel

.Net Digital Rights Management-exempel visar hur du implementerar ett multi-DRM-system med Media Services v3 med hjälp av .NET.

Det finns ytterligare innehållsskyddsexempel för Node.JS och Python:

Få hjälp och support

Du kan kontakta Media Services med frågor eller följa våra uppdateringar med någon av följande metoder:

• Q & A
• Stack Overflow. Tagga frågor med azure-media-services.
• @MSFTAzureMedia eller använd @AzureSupport för att begära support.
• Öppna en supportbegäran via Azure Portal.