Impeça a distribuição não autorizada

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

A RFC 2616 oferece as seguintes opções para ajudar a proteger o seu conteúdo contra a distribuição não autorizada.

  • Tokens (abordagem recomendada): a RFC de multimédia usa tokens para ajudar a proteger o conteúdo.

    Um token é um meio de trocar pedidos assinados, como um cookie assinado, um URI com parâmetros de consulta ou um componente de caminho. Os tokens válidos apresentados pelos visitantes são usados para autenticar o acesso ao seu conteúdo. Um visitante com um token inválido ou um token em falta é impedido de aceder ao seu conteúdo.

    Pode optar por usar a autenticação com um único token ou com dois tokens. São necessários tokens para a autenticação de dois tokens.

    Quando a autenticação de dois tokens é usada, a RFC de multimédia usa dois tokens: um token de curta duração e um token de longa duração.

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

    • Oferecer compatibilidade com redes de fornecimento de conteúdo (RFCs) que não sejam da Google.
    • Suporte a assinatura apenas de caminhos.
    • Ativar a assinatura de vários cabeçalhos.
    • Oferecer controlo e revogação de acesso detalhados.
    • Minimize o impacto dos tokens comprometidos.
    • Pode incorporar dados arbitrários e IDs de sessões.

  • Assinaturas: a RFC de multimédia usa uma única assinatura para ajudar a proteger o conteúdo. As assinaturas permitem-lhe fazer a assinatura do URL completo, incluindo o anfitrião e o protocolo.

Pode usar ambas as opções em conjunto para ajudar a proteger o seu conteúdo.

Como funciona a autenticação com dois tokens

A autenticação de dois tokens usa dois tokens para autenticar pedidos ao seu conteúdo: um token de curta duração para o início da reprodução e um token de longa duração para o resto da sessão de reprodução.

Para usar a autenticação de dois tokens, configure o servidor de aplicações para emitir tokens de curta duração para agentes do utilizador. Em seguida, configure a RFC de inserção intercalar para responder aos tokens de curta duração. Pode colocar o token num parâmetro de consulta à sua escolha ou num cookie. Para mais informações, consulte o artigo Use a autenticação de dois tokens.

Os tokens de curta duração gerados pelo servidor de aplicações ajudam a proteger os manifestos principais (por vezes, denominados playlists multivariantes). A expiração do pedido assinado é suficientemente curta para pedir um manifesto principal, mas não para ver todo o conteúdo contido num manifesto.

Quando a RFC recebe um pedido com um token autorizado de curta duração, gera um token assinado de longa duração. Pode usar o token num parâmetro de consulta com um único nome ou num cookie. O token de longa duração permite ver um programa completo. Os tokens de longa duração assinados gerados pela RFC de multimédia na nuvem usam assinaturas Ed25519 que são assinadas com a chave privada Google-owned and managed keys associada a um recurso EdgeCacheKeyset.

Pode personalizar o tempo de expiração dos tokens de curta e longa duração. Como prática recomendada, a Google recomenda que configure o tempo de expiração dos tokens de curta duração gerados no servidor da sua aplicação para um minuto. Tem de definir a hora de validade dos tokens de longa duração gerados pela RFC 2616 para uma duração superior à duração do conteúdo, até um máximo de um dia.

Fluxo de pedidos para autenticação de token duplo

A descrição seguinte descreve o fluxo de pedidos:

  1. Um visitante pede metadados ao servidor de aplicações para conteúdo multimédia que quer ver. O servidor de aplicações devolve o URI do manifesto principal assinado com um token de curta duração.

  2. A sua aplicação de leitor pede o manifesto principal à RFC de conteúdo multimédia. O pedido inclui o token de curta duração como um valor de um parâmetro de consulta URI no formato de parâmetro de consulta com nome único.

  3. A RFC verifica o token de curta duração e os parâmetros assinados do token.

    1. Se o token for válido, a RFC cria um token de assinatura de longa duração. A RFC de multimédia devolve o token num cabeçalho Set-Cookie ou modificando os URIs do manifesto e do segmento no manifesto principal para incluir o token.
    2. Se o token não for válido, a RFC de multimédia responde com uma resposta HTTP 403 Forbidden.

  4. A aplicação do leitor recebe o manifesto principal da RFC de multimédia e, em seguida, pede a playlist de multimédia ou os segmentos de multimédia referenciados no manifesto principal. O pedido tem de incluir o token de longa duração, como um cookie assinado ou como um parâmetro de URI.

  5. A RFC de multimédia valida o token de assinatura de longa duração:

    1. Se o token de longa duração for válido para o pedido específico, a RFC de multimédia serve o conteúdo pedido.
    2. Se o token de longa duração não for válido (devido a um token expirado ou a um caminho inválido), a RFC de multimédia responde com uma resposta HTTP 403 Forbidden.

  6. O processo repete-se até a reprodução de multimédia terminar ou a assinatura de longa duração expirar.

Formatos de tokens suportados para pedidos assinados com dois tokens

Os pedidos assinados com dois tokens da RFC são compatíveis com vários formatos, dependendo do tipo de token.

Pedidos assinados de curta duração

Para pedidos assinados de curta duração, a RFC de multimédia na nuvem suporta tokens assinados com assinaturas Ed25519 por predefinição. Também pode usar códigos de autenticação de mensagens baseados em hash de chave simétrica (HMACs) para compatibilidade com o código da aplicação existente e outras RFCs.

Para usar HMACs, use o Secret Manager para armazenar o segredo HMAC. Em seguida, concede acesso à conta de serviço do Media CDN para aceder ao segredo armazenado. Como prática recomendada, a Google recomenda a utilização de assinaturas assimétricas com assinaturas Ed25519 para segurança e desempenho.

A conta de serviço da RFC de multimédia é propriedade do projeto da RFC de multimédia e não é apresentada na lista de contas de serviço do seu projeto. A conta de serviço concede acesso apenas aos recursos da Media CDN nos projetos que permite 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 seu projeto.

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

Pedidos assinados de longa duração

Para pedidos assinados de longa duração, a RFC de multimédia usa assinaturas Ed25519 assinadas com Google-owned and managed keys associadas a um recurso EdgeCacheKeyset.

A RFC suporta um formato de token único para tokens de longa duração, que podem ser usados num parâmetro de consulta com um único nome para streams HLS ou num cookie.

Como funcionam os pedidos assinados

Um pedido assinado usa assinaturas ou tokens para verificar se cada visitante está autenticado para aceder ao conteúdo. Pode configurar a RFC de multimédia para que o acesso seja limitado a qualquer um dos seguintes elementos:

  • Um URI exato ou um prefixo de URI por um período limitado
  • Um cliente específico
  • Para pedidos assinados que usam tokens, até cinco caminhos com carateres universais

Para usar pedidos assinados, gera chaves para assinar e validar assinaturas. Em seguida, configura as rotas, que lhe permitem otimizar o comportamento com base no tipo de conteúdo, nos atributos do cliente e nos seus requisitos de atualidade. Os pedidos assinados podem ser aplicados por rota, o que ajuda a proteger pontos finais específicos.

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

Pode configurar a RFC de multimédia para usar pedidos assinados ou tokens para ajudar a proteger o conteúdo.

Para pedidos assinados com tokens, pode colocar o token num dos seguintes locais:

  • Num parâmetro de consulta à sua escolha
  • Num cookie

Para mais informações, consulte Gere tokens.

Para pedidos assinados com assinaturas, pode usar qualquer um dos seguintes formatos:

  • Um URI exato com parâmetros de consulta: especifica um URLPrefix com o URI exato e anexa os mesmos parâmetros de consulta a vários URIs.
  • Um prefixo de URI com parâmetros de consulta: especifica um URLPrefix com um prefixo de URI e anexa os mesmos parâmetros de consulta a vários URIs.
  • Um componente do caminho: especifica um componente do caminho que permite que os URIs do manifesto relativos herdem o componente do URI assinado.
  • Um cookie assinado: especifica um prefixo de URI num cookie, o que permite o acesso a qualquer URI com o prefixo que especificou.

Para mais informações, consulte o artigo Gere assinaturas.

Considerações

As secções seguintes abordam vários fatores a ter em conta para ajudar a evitar a distribuição não autorizada do seu conteúdo.

Considerações de segurança

A RFC de multimédia valida todos os pedidos que correspondem a uma rota configurada com um cdnPolicy.signedRequestMode de REQUIRE_SIGNATURES ou REQUIRE_TOKENS.

Recomendamos que valide os pedidos na sua origem. Embora o Media CDN rejeite pedidos inválidos e não assinados para uma rota que exija assinaturas, os clientes podem encontrar uma forma de aceder diretamente à sua origem. Uma camada adicional de validação ajuda a fornecer uma abordagem de defesa em profundidade para proteger o seu conteúdo.

A tabela seguinte explica os cenários em que a RFC de multimédia valida um pedido:

O pedido tem assinatura Assinatura válida? signedRequestMode Comportamento Código de estado
Não N/A REQUIRE_SIGNATURES ou REQUIRE_TOKENS As solicitações sem assinaturas nem tokens são tratadas como se a assinatura fosse inválida. HTTP 403
Sim Não REQUIRE_SIGNATURES ou REQUIRE_TOKENS Uma assinatura ou um token é considerado inválido se tiver expirado ou tiver um URL em conflito ou uma chave incorreta. As assinaturas ou os tokens inválidos são rejeitados no limite da RFC. HTTP 403
Sim Sim REQUIRE_SIGNATURES ou REQUIRE_TOKENS É validada uma assinatura ou um token, e a resposta é publicada com conteúdo de uma cache ou da origem. HTTP 200
Sim Sim Nenhum ou DISABLED Não é feita nenhuma validação e é apresentada uma resposta diretamente ao utilizador. HTTP 200
Sim Não Nenhum ou DISABLED Não é feita nenhuma validação e é apresentada uma resposta diretamente ao utilizador. HTTP 200

Quando a sua aplicação deteta uma assinatura inválida, certifique-se de que a aplicação responde com um código de estado HTTP 403 (Forbidden). Os códigos de estado HTTP 403 não são armazenáveis em cache.

Se a sua aplicação enviar um código de estado memorizável em cache para um pedido inválido, os pedidos futuros válidos podem ser rejeitados incorretamente.

Limites de URI

A maioria dos clientes HTTP modernos suporta URIs com um comprimento máximo de 8000 carateres. No entanto, alguns dispositivos antigos ou de nicho podem ter limites mais rigorosos. Em geral, um URI assinado adiciona cerca de 125 carateres ao URI do pedido, que inclui o seguinte:

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

Como prática recomendada, mantenha os URIs com menos de 2000 carateres usando parâmetros de consulta como tokens. Os URIs mais curtos impedem que os dispositivos enviem URIs truncados para a rede de CDN de multimédia.

Dispositivos de streaming de vídeo antigos

Alguns dispositivos de streaming de vídeo antigos podem não suportar totalmente a anexação de cookies a pedidos de manifesto ou de segmento de multimédia. Se tiver dispositivos com problemas conhecidos no processamento de cookies HTTP, configure a RFC de multimédia para usar parâmetros de consulta para pedidos assinados e troca de tokens duplos.

É o único responsável por qualquer conformidade com o consentimento e a privacidade exigida quando usa cookies para trocar tokens de curta duração. Quando a RFC de conteúdo multimédia está configurada para usar pedidos assinados com dois tokens, a Google emite e gere os cookies usados para tokens de longa duração.

Faturação

Para saber mais sobre a faturação do Secret Manager, consulte a secção Preços.

As obtenções de Secrets da RFC do CDN de multimédia são armazenadas em cache internamente, o que reduz significativamente a taxa de obtenções de Secrets do Secret Manager. As obtenções reduzidas também diminuem significativamente as taxas de acessos que o Secret Manager observa e pelas quais lhe fatura.

Para mais informações sobre o armazenamento em cache de segredos no Media CDN, consulte o artigo Vista geral das chaves.