Visão geral de URLs e cookies assinados

Com URLs e cookies assinados do Cloud CDN, é possível exibir respostas dos caches distribuídos globalmente do Google Cloud, mesmo quando as solicitações forem necessárias para autorização.

URLs e cookies assinados do Cloud CDN alcançam metas semelhantes: ambos controlam o acesso ao conteúdo armazenado em cache. Antes de veicular conteúdo dos caches distribuídos globalmente do Google Cloud e decidir entre URLs ou cookies assinados, compare de casos de uso a seguir.

URLs assinados

Um URL assinado fornece permissão e tempo limitados para fazer uma solicitação.

Casos de uso

Em alguns cenários, talvez você não queira exigir uma Conta do Google para os usuários acessarem o conteúdo do Cloud CDN, mas ainda quer controlar o acesso usando a lógica específica do aplicativo.

A maneira comum de abordar esse caso de uso é fornecer um URL assinado a um usuário, o que dá a ele o acesso de leitura a esse recurso por um tempo limitado. Ao criar o URL assinado, você especifica um prazo de validade. Qualquer pessoa que tenha o URL pode acessar o recurso até que o prazo de validade do URL seja atingido ou a chave usada para assinar o URL seja rotacionada.

Use URLs assinados nos seguintes casos:

  • É preciso restringir o acesso a arquivos individuais, como um download de instalação.

  • Seus usuários estão usando aplicativos clientes que não são compatíveis com cookies.

Como os URLs assinados funcionam

Os URLs assinados fornecem ao cliente acesso temporário a um recurso particular sem precisar de outra autorização. Para isso, os elementos selecionados de uma solicitação são assinados com criptografia e identificados com hash usando uma chave fortemente aleatória gerada por você.

Quando uma solicitação usa o URL assinado que você forneceu, ela é considerada autorizada para receber o conteúdo solicitado. Quando o Cloud CDN recebe uma solicitação com uma assinatura inválida para um serviço ativado, a solicitação é rejeitada e não é encaminhada ao back-end para processamento.

Geralmente, um URL assinado pode ser usado por qualquer pessoa que o tenha. No entanto, ele é destinado apenas ao cliente que o recebeu. Para reduzir o risco de o URL ser usado por um cliente diferente, ele expira no momento determinado por você. Para minimizar o risco de um URL assinado ser compartilhado, defina a expiração dele para o quanto antes possível.

Como os URLs são assinados

Antes de assinar URLs, crie uma ou mais chaves criptográficas em um serviço de back-end, um bucket de back-end ou em ambos. Em seguida, assine e criptografe um URL com hash usando a CLI do Google Cloud ou seu próprio código.

Como processar URLs assinados

Quando o processamento de URLs assinados estiver ativado em um back-end, o Cloud CDN fornecerá um processamento especial para solicitações com URLs assinados. Especificamente, as solicitações com um parâmetro de consulta Signature são consideradas assinadas. Quando tal solicitação é recebida, o Cloud CDN verifica:

  1. O método HTTP é GET, HEAD, OPTIONS ou TRACE.
  2. se o parâmetro Expires é definido como um horário futuro;
  3. se a assinatura da solicitação corresponde à assinatura calculada usando a chave nomeada.

Se alguma dessas verificações falhar, uma resposta 403 Forbidden será exibida. Caso contrário, a solicitação será intermediada por proxy para o back-end ou veiculada a partir do cache. As solicitações OPTIONS e TRACE são sempre encaminhadas por proxy diretamente para o back-end e não são veiculadas a partir do cache. Todas as solicitações assinadas válidas para um determinado URL base (a parte antes do parâmetro Expires) compartilham a mesma entrada de cache. As respostas para solicitações assinadas e não assinadas não compartilham as entradas de cache. As respostas serão armazenadas em cache e veiculadas até o prazo de validade definido por você.

Em geral, o conteúdo que requer solicitações assinadas é marcado como não armazenável em cache usando o cabeçalho Cache-Control. Para tornar esses objetos compatíveis com o Cloud CDN, sem a necessidade de alterações de back-end, ele substitui o cabeçalho Cache-Control ao responder às solicitações com URLs assinados válidos. O Cloud CDN trata o conteúdo como armazenável em cache e usa o parâmetro max-age definido em sua configuração. A resposta veiculada ainda tem os cabeçalhos Cache-Control gerados pelo back-end.

O URL retornado da CLI do Google Cloud ou produzido pelo seu código personalizado pode ser distribuído de acordo com suas necessidades. Recomendamos assinar somente URLs de HTTPS, porque o HTTPS fornece um transporte seguro que impede a interceptação do componente de assinatura do URL assinado. Da mesma maneira, é necessário distribuir os URLs assinados em protocolos de transporte seguros, como TLS/HTTPS.

Cookies assinados

Um cookie assinado fornece permissão e tempo limitados para fazer solicitações para um conjunto de arquivos.

Casos de uso

Use cookies assinados se:

  • precisar fornecer acesso a vários arquivos restritos;

  • quiser evitar a alteração dos URLs atuais;

  • quiser evitar a atualização de URLs sempre que atualizar a autorização para acessar o conteúdo.

Como fazer streaming de mídia usando HLS e DASH

Se você exibe conteúdo de vídeo e áudio usando os protocolos HTTP Live Streaming (HLS) ou Dynamic Adaptive Streaming over HTTP (DASH), é comum gerar um manifesto com uma lista de URLs para segmentos de vídeo e áudio. É possível ter várias instâncias de cada segmento para fornecer codificações diferentes (codec, taxa de bits, resolução) a um cliente.

É possível usar os URLs assinados do Cloud CDN para assinar e autorizar o acesso a cada um deles, mas gerar dinamicamente todas as combinações possíveis por usuário é trabalhoso e aumenta a carga de origem e a complexidade do aplicativo.

Os cookies assinados foram criados para resolver esse problema. É possível fornecer ao usuário um cookie assinado que o autorize a acessar qualquer conteúdo correspondente a uma política (prefixo de URL e data de validade) sem precisar gerar ou assinar seus manifestos de mídia individualmente. Se quiser, atualize o acesso do usuário periodicamente por meio da API fetch() para JavaScript na navegação nas páginas ou em outros mecanismos em segundo plano em aplicativos nativos. A capacidade de atualizar o acesso do usuário também permite o uso de tempos de validade curtos, dificultando o compartilhamento de conteúdo protegido.

É possível emitir esses cookies para usuários com vários clientes de navegador e outros clientes compatíveis com HTTP, como o ExoPlayer do Google e o AVPlayer do iOS.

Downloads binários (jogos)

Assim como o streaming de mídia, se você fornecer downloads de clientes de jogos, será possível dividir grandes dados de jogos ou patches de vários gigabytes em blocos menores para oferecer compatibilidade com armazenamento em cache mais refinado, invalidação e simultaneidade.

Em geral, esses blocos são listados em um manifesto. Os cookies assinados permitem a autorização do acesso a esses downloads apenas para usuários autenticados sem exigir modificações no manifesto e, como acontece com os URLs assinados, sem abrir mão dos benefícios do armazenamento em cache do Cloud CDN.

Como os cookies assinados funcionam

Configurar e emitir cookies assinados requer três passos:

  • Criar uma chave de assinatura para o serviço de back-end fornecido.
  • Criar um valor de cookie com o prefixo de URL permitido, a validade, o nome da chave e a assinatura criptográfica.
  • Emitir o cookie no código do aplicativo.

O Cloud CDN valida esses cookies assinados quando eles são incluídos com solicitações.

Para impedir que os usuários burlem os controles de cookies assinados, use um bucket do Cloud Storage. Para isso, restrinja o acesso ao bucket subjacente removendo o papel allUsers e concedendo à conta de serviço do Cloud CDN acesso de leitura ao bucket.

Da mesma forma, as instâncias de máquina virtual (VM) precisam validar as assinaturas em todas as solicitações assinadas que veiculam.

Advertências e limitações

  • Você é o único responsável por qualquer consentimento e conformidade de privacidade necessários para os cookies assinados. Eles são emitidos e gerenciados por você, não pelo Google.

  • Se você usar URLs e cookies assinados para controlar o acesso aos mesmos arquivos, e um visualizador usar um URL assinado para solicitar um arquivo, o Cloud CDN determinará se esse arquivo será retornado para o visualizador apenas com base no URL assinado. O Cloud CDN só considera cookies assinados se o URL não estiver assinado.

  • Se você tiver configurado o serviço para solicitações assinadas e seu URL incluir Signature como um parâmetro de consulta, o Cloud CDN tentará interpretá-lo como um URL assinado. Se o Cloud CDN tentar tratar seu URL como assinado quando você não quiser, ele provavelmente não será um URL assinado válido. Portanto, ele será rejeitado pelo Cloud CDN.

  • Navegadores e outros clientes costumam impor limites de tamanho de cookie (4 KB por cookie) e uma contagem total de 50 por domínio, de acordo com a RFC 6265. Considere o payload total do cookie enviado do domínio.

  • Os limites e as restrições do Cloud CDN são aplicáveis, incluindo o máximo de três chaves de solicitação assinadas por back-end.

  • As solicitações assinadas não são cobradas de maneira diferente das solicitações atuais do Cloud CDN, mas as solicitações com falha (rejeitadas), como aquelas com assinaturas expiradas ou inválidas, ainda incorrem em cobranças de pesquisa de cache.

A seguir