Impedir a distribuição não autorizada

Esta página descreve brevemente as opções que o Media CDN oferece para ajudam a impedir a distribuição não autorizada do seu conteúdo.

O Media CDN oferece as opções a seguir para ajudar a proteger seu conteúdo contra distribuição não autorizada.

  • Tokens (abordagem recomendada): o Media CDN usa tokens para proteger o conteúdo.

    Um token é um meio de troca de solicitações assinadas, como um cookie assinado, um URI com parâmetros de consulta ou um componente de caminho. Tokens válidos apresentados por espectadores são usados para autenticar o acesso ao seu conteúdo. Um espectador com um um token inválido ou um token ausente for impedido de acessar seu conteúdo.

    Você pode optar por usar autenticação de token único ou de dois tokens. Os tokens são necessários para a autenticação de dois tokens.

    Quando a autenticação de dois tokens é usada, a Media CDN usa dois tokens, um de curta duração e outro de longa duração.

    O Google recomenda tokens para novas integrações porque eles oferecem as seguintes vantagens:

    • Oferecer compatibilidade com redes de fornecimento de conteúdo (CDNs) que não são do Google.
    • Suporte à assinatura somente de caminho.
    • Ativar a assinatura de vários cabeçalhos.
    • Oferecem controle de acesso granular e revogação.
    • Minimizar o impacto de tokens comprometidos.
    • Pode incorporar dados arbitrários e IDs de sessão.
  • Assinaturas: o Media CDN usa uma única assinatura para ajudar proteger o conteúdo. As assinaturas permitem a assinatura de URLs completos, incluindo o host e o protocolo.

Você pode usar as duas opções juntas para ajudar a proteger seu conteúdo.

Como funciona a autenticação de token duplo

A autenticação de dois tokens usa dois tokens para autenticar solicitações ao seu conteúdo: um token de curta duração para iniciar a reprodução e um de longa duração token para o restante da sessão de reprodução.

Para usar a autenticação de dois tokens, configure o servidor do aplicativo para emitir tokens de curta duração para agentes do usuário. Em seguida, configure o Media CDN para responder aos tokens de curta duração. Você pode colocar o token em um parâmetro de consulta de sua escolha ou colocar o token em um cookie. Para mais informações, consulte Usar a autenticação de token duplo.

Tokens de curta duração gerados pelo servidor do aplicativo ajudam a proteger os (às vezes chamadas de playlists multivariantes). O a expiração da solicitação assinada for curta o suficiente para solicitar um manifesto principal; mas não observar todo o conteúdo contido em um manifesto.

Quando o Media CDN recebe uma solicitação com um token de curta duração autorizado, ele gera um token de longa duração assinado. É possível usar o token em um parâmetro de consulta com nome único ou em um cookie. O token de longa duração suporta a visualização de um programa completo. Os tokens assinados de longa duração geradas pelo Media CDN usam assinaturas Ed25519 assinadas com as chaves gerenciadas pelo Google associadas a uma Recurso EdgeCacheKeyset.

É possível personalizar o prazo de validade de tokens de curta e longa duração. Como prática recomendada, o Google recomenda que você configure o prazo de validade de curta duração gerados no servidor do aplicativo para um minuto. Você precisa definir o prazo de validade dos tokens de longa duração que o Media CDN é gerada com uma duração maior que a do conteúdo, até um máximo de um dia.

Fluxo de solicitação para autenticação de token duplo

Confira a seguir a descrição do fluxo de solicitações:

  1. Um espectador solicita metadados do servidor do aplicativo para a mídia que ele quer assistir. O servidor de aplicativos retorna o URI do manifesto principal assinado com um token de curta duração.

  2. O aplicativo do seu player solicita o manifesto principal de Media CDN do Google Cloud. A solicitação inclui o token de curta duração como um valor de um parâmetro de consulta do URI no formato de parâmetro de consulta com nome único.

  3. O Media CDN verifica o token de curta duração e o parâmetros com sinal.

    1. Se o token for válido, o Media CDN criará um token de assinatura. O Media CDN retorna o token em uma cabeçalho Set-Cookie ou modificando o manifesto e os URIs do segmento na manifesto principal para incluir o token.
    2. Se o token não for válido, o Media CDN vai responder com uma resposta HTTP 403 Forbidden.
  4. O aplicativo do jogador recebe o manifesto principal do Media CDN e, em seguida, solicita a playlist de mídia ou o referenciados no manifesto principal. A solicitação precisa incluir o token de longa duração, como um cookie assinado ou um parâmetro de URI.

  5. O Media CDN verifica o token de assinatura de longa duração:

    1. Se o token de longa duração for válido para a solicitação específica, o Media CDN vai disponibilizar o conteúdo solicitado.
    2. Se o token de longa duração não for válido (devido a um token expirado ou a um caminho inválido), o Media CDN vai responder com uma resposta HTTP 403 Forbidden.
  6. O processo se repete até que a reprodução da mídia termine ou até que a assinatura de longa duração seja concluída. expira.

Formatos de token aceitos para solicitações assinadas com dois tokens

As solicitações assinadas com token duplo do Media CDN são compatíveis com vários formatos, dependendo do tipo de token.

Solicitações assinadas de curta duração

Para solicitações assinadas de curta duração, o Media CDN oferece suporte a tokens assinados com assinaturas Ed25519 por padrão. Você também pode usar códigos de autenticação de mensagens com base em hash de chave simétrica (HMACs) para compatibilidade com o código do aplicativo e outras CDNs.

Para usar HMACs, utilize o Secret Manager para armazenar o secret HMAC. Em seguida, você concede acesso à conta de serviço do Media CDN para acessar o secret armazenado. O Google recomenda usando assinatura assimétrica com assinaturas Ed25519 para segurança e desempenho.

A conta de serviço do Media CDN pertence ao do Media CDN e não será exibido na lista de e contas de serviço. A conta de serviço concede acesso apenas Recursos do Media CDN nos projetos que você permitir explicitamente.

A conta de serviço tem o seguinte formato:

service-PROJECT_NUMBER@gcp-sa-mediaedgefill.iam.gserviceaccount.com

Em que PROJECT_NUMBER é o número do projeto.

Para ativar a conta de serviço do CDN de mídia, crie pelo menos um recurso do CDN de mídia, como EdgeCacheOrigin.

Solicitações assinadas de longa duração

Para solicitações assinadas de longa duração, o Media CDN usa assinaturas Ed25519 assinhadas com chaves gerenciadas pelo Google associadas a um recurso EdgeCacheKeyset.

O Media CDN oferece suporte a um formato de token único para tokens de longa duração, que pode ser usado em um parâmetro de consulta de nome único para fluxos HLS ou em um cookie.

Como funcionam as solicitações assinadas

Uma solicitação assinada usa assinaturas ou tokens para verificar se todos os espectadores foram autenticados para acessar o conteúdo. É possível configurar o Media CDN para que o acesso tem escopo para qualquer um destes itens:

  • Um URI exato ou um prefixo de URI por um tempo limitado
  • Um cliente específico
  • Para solicitações assinadas que usam tokens, até cinco caminhos com caracteres curinga

Para usar solicitações assinadas, gere chaves para assinar e verificar assinaturas. Em seguida, você configura rotas, que permitem otimizar o comportamento com base no tipo de conteúdo, nos atributos do cliente e nos seus requisitos de atualização. As solicitações assinadas podem ser aplicadas por rota, o que ajuda a proteger endpoints específicos.

Cada serviço de CDN de mídia pode usar uma coleção de várias chaves. A coleção de chaves também é conhecida como conjunto de chaves. Os conjuntos de chaves permitem girar chaves e distribuir chaves privadas na sua própria infraestrutura sem interrupções.

É possível configurar o Media CDN para usar solicitações assinadas ou para ajudar a proteger o conteúdo.

Para solicitações assinadas usando tokens, é possível colocar o token em um dos seguintes:

  • Em um parâmetro de consulta escolhido por você
  • Em um cookie

Para mais informações, consulte Gerar tokens.

Para solicitações assinadas usando assinaturas, é possível usar qualquer um dos seguintes formatos:

  • Um URI exato com parâmetros de consulta: especifique um URLPrefix com o URI exato e anexe os mesmos parâmetros de consulta a vários URIs.
  • Um prefixo URI com parâmetros de consulta: especifique um URLPrefix com um prefixo URI e anexe os mesmos parâmetros de consulta a vários URIs.
  • Um componente de caminho: você especifica um componente de caminho, que permite que os os URIs do manifesto herdam o componente de URI assinado.
  • Um cookie assinado: você especifica um prefixo URI em um cookie, o que permite acesso a qualquer URI com o prefixo especificado.

Para mais informações, consulte Gerar assinaturas.

Considerações

As seções a seguir discutem vários fatores a serem considerados para ajudar a impedir a distribuição não autorizada do seu conteúdo.

Considerações sobre segurança

O Media CDN valida todas as solicitações que correspondem a uma rota configurada com um cdnPolicy.signedRequestMode de REQUIRE_SIGNATURES ou REQUIRE_TOKENS.

Recomendamos que você valide as solicitações na origem. Embora o Media CDN rejeite solicitações inválidas e não assinadas para uma rota que exija assinaturas, os clientes podem encontrar uma maneira de acessar sua origem diretamente. Um camada adicional de validação que ajuda a fornecer uma abordagem de defesa em profundidade para proteger seu conteúdo.

A tabela a seguir explica os cenários em que o Media CDN valida uma solicitação:

A solicitação tem uma assinatura Assinatura válida? signedRequestMode Comportamento Código de status
Não N/A REQUIRE_SIGNATURES ou REQUIRE_TOKENS As solicitações sem assinaturas ou tokens são tratadas como se a assinatura fosse inválida. HTTP 403
Sim Não REQUIRE_SIGNATURES ou REQUIRE_TOKENS Uma assinatura ou token é considerado inválido se estiver expirado ou tiver um URL incorreto ou uma chave incorreta. Assinaturas ou tokens inválidos são rejeitados na borda da CDN. HTTP 403
Sim Sim REQUIRE_SIGNATURES ou REQUIRE_TOKENS Uma assinatura ou um token é validado e a resposta é fornecida com conteúdo de um cache ou da origem. HTTP 200
Sim Sim Nenhum ou DISABLED Nenhuma validação é realizada, e uma resposta é enviada diretamente ao usuário. HTTP 200
Sim Não Nenhum ou DISABLED Nenhuma validação é realizada, e uma resposta é enviada diretamente ao usuário. HTTP 200

Quando o seu aplicativo detectar uma assinatura inválida, verifique se o seu o aplicativo responde com um código de status HTTP 403 (Forbidden). Os códigos de status HTTP 403 não podem ser armazenados em cache.

Caso seu aplicativo envie um código de status armazenável em cache para uma solicitação, solicitações válidas futuras poderão ser rejeitadas incorretamente.

Limites de URI

A maioria dos clientes HTTP modernos aceita URIs de até 8.000 caracteres. No entanto, alguns os dispositivos legados ou de nicho podem ter limites mais rigorosos. Em geral, um URI assinado adiciona cerca de 125 caracteres para o URI de solicitação, que inclui o seguinte:

  • Se todos os nomes de campo forem usados, aproximadamente 67 caracteres para cada campo (como Expires= e KeyName=).
  • Para o carimbo de data/hora Unix, 10 caracteres
  • Para a KeyName, cinco caracteres
  • Para o valor Signature codificado em base64, 43 caracteres

Como prática recomendada, mantenha URIs com menos de 2.000 caracteres usando parâmetros de consulta como tokens. URIs mais curtos impedem que os dispositivos enviem URIs truncados ao Media CDN.

Dispositivos de streaming de vídeo legados

Alguns dispositivos de streaming de vídeo legados podem não suportar totalmente o anexo de cookies a manifesto ou segmento de mídia. Se você tiver dispositivos com problemas conhecidos no processamento de cookies HTTP, configure o Media CDN para usar parâmetros de consulta para solicitações assinadas e troca de dois tokens.

Você é a única pessoa responsável por qualquer consentimento e conformidade de privacidade necessários ao usando cookies para a troca de tokens de curta duração. Quando o Media CDN é configurado para usar solicitações assinadas com dois tokens, o Google emite e gerencia os cookies usados para tokens de longa duração.

Faturamento

Para saber mais sobre como o Secret Manager é cobrado, consulte Preços.

As buscas do Media CDN de secrets são armazenadas em cache internamente, significativamente reduzindo a taxa de buscas de secrets do Secret Manager. As transferências reduzidas também reduzem significativamente as taxas de acessos que o Secret Manager observa e cobra.

Para mais informações sobre o armazenamento em cache de secrets no Media CDN, consulte Visão geral das chaves.