Use pedidos assinados

Para criar um pedido assinado, componha uma string que inclua parâmetros que descrevam o conteúdo que quer proteger e a hora de validade do valor assinado. Em seguida, inclui a string composta no seu pedido. Em seguida, a RFC de multimédia verifica se o seu pedido assinado é válido antes de agir em conformidade.

Requisitos de pedidos assinados

Os pedidos assinados têm de cumprir os seguintes requisitos:

  • Ter um método HTTP GET, HEAD ou OPTIONS. Outros métodos não são suportados.

  • Ter uma hora de validade definida no futuro. Devido a potenciais diferenças de sincronização do relógio, bem como às condições da rede do cliente (por exemplo, desconexões e novas tentativas), recomendamos que defina as indicações de tempo, pelo menos, um minuto no futuro ou, pelo menos, a duração da stream de vídeo, consoante o que for superior.

  • Ter uma assinatura que possa ser validada por uma chave ou um segredo num EdgeCacheKeyset.

Não pode assinar outros métodos HTTP, como pedidos POST, PUT ou DELETE. Se precisar de emitir URLs assinados para carregamentos acessíveis aos utilizadores, consulte a documentação do Cloud Storage sobre URLs assinados.

Configure pedidos assinados

As secções seguintes detalham como configurar, assinar e validar pedidos assinados.

Gere chaves

Crie as chaves que a RFC de multimédia usa para assinar pedidos.

Crie um conjunto de chaves

Crie o conjunto de chaves que a RFC de multimédia usa para pedidos assinados.

Requerer pedidos assinados

Para permitir que apenas os pedidos assinados acedam a um recurso, pode anexar uma lista de chaves a uma rota e definir o signedRequestMode para um dos seguintes:

  • REQUIRE_SIGNATURES para pedidos assinados que não usam tokens.

  • REQUIRE_TOKENS para pedidos assinados com tokens.

A ativação de pedidos assinados numa rota garante que todos os pedidos são assinados ou apresentam um token. As solicitações sem uma assinatura válida (como um nome de chave inválido, uma assinatura ou um token expirado, uma assinatura não correspondente, etc.) falham.

Um EdgeCacheKeyset pode conter várias chaves para permitir a rotação de chaves. Os pedidos válidos assinados com qualquer chave listada são aceites e as chaves são tentadas por ordem. Para mais informações sobre a rotação de chaves, consulte o artigo Rote os segredos.

Quando o signedRequestMode está definido como REQUIRE_SIGNATURES ou REQUIRE_TOKENS, a RFC valida os acertos e os erros de cache. Isto inclui todos os pedidos à origem.

Segue-se um exemplo de uma configuração da RFC de multimédia que aplica pedidos assinados num determinado PathMatcher (rota):

gcloud edge-cache services describe prod-media-service
Saída: 
...
  routeAction:
    cdnPolicy:
      cacheMode: CACHE_ALL_STATIC
      signedRequestMode: REQUIRE_SIGNATURES
      signedRequestKeyset: prod-vod-keyset

Para obter informações sobre como criar tokens para pedidos assinados, consulte Gerar tokens.

Para desativar a assinatura de pedidos, pode definir o signedRequestMode como DISABLED e eliminar a referência ao signedRequestKeyset.

Valide os pedidos na origem

Quando uma rota é configurada com um modo de assinatura de REQUIRE_SIGNATURES, a RFC de multimédia valida se cada pedido correspondente tem uma assinatura válida. A falta de uma assinatura é tratada como uma assinatura inválida para estas rotas.

Para evitar casos em que a assinatura está configurada incorretamente e em que um utilizador tenta aceder diretamente à sua origem, recomendamos que valide se os pedidos também estão assinados na origem. Uma abordagem de defesa em profundidade à proteção de conteúdo ajuda a impedir o acesso e a transferência não autorizados do seu conteúdo licenciado e pago.

Para métodos de assinatura baseados em URL, em que a assinatura faz parte dos parâmetros de consulta ou está incorporada como um componente do caminho do URL, a assinatura e os parâmetros relacionados são removidos do URL antes de o pedido ser enviado para a origem. Isto impede que a assinatura cause problemas de encaminhamento quando a origem está a processar o pedido. Para validar estes pedidos, pode inspecionar o cabeçalho do pedido x-client-request-url, que inclui o URL do pedido do cliente original (assinado) antes da remoção dos componentes assinados.

Para validar pedidos na origem, use o mesmo código de validação como parte dos seus pontos finais de assinatura de pedidos, o que também ajuda a mitigar a incompatibilidade de chaves e os problemas devido à alteração de chaves.

Alterne chaves

Como prática recomendada, rode ou atualize os segredos usados pela Media CDN regularmente. Recomendamos que rode as chaves a cada 30 a 60 dias, mas não é estritamente necessário.

O que se segue?

  • Para ler mais sobre como ativar e aceder aos registos da RFC de multimédia, incluindo como filtrar e consultar os seus registos, consulte Registo.

  • Para configurar o Media CDN e um contentor do Cloud Storage privado, consulte o artigo Conetividade e proteção de origem.