Autenticar conteúdo

O Cloud CDN oferece três maneiras para ajudar você a controlar o acesso ao seu conteúdo em cache:

  • Os URLs assinados permitem veicular respostas dos caches distribuídos globalmente do Google Cloud quando solicitações são necessários para autorização. Qualquer pessoa com o URL assinado pode acessar o recurso por tempo limitado.
  • Os cookies assinados também permitem acessar um recurso por tempo limitado. Eles são úteis quando é necessário assinar dezenas ou centenas de URLs para cada usuário.
  • A autenticação de origem particular permite limitar as conexões aos buckets do Amazon Simple Storage Service (Amazon S3) ou a outros armazenamentos de objetos compatíveis e impedir que os usuários os acessem diretamente.

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:

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

  • Para atender a usuários com aplicativos cliente 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:

  • O método HTTP é GET, HEAD, OPTIONS ou TRACE.
  • se o parâmetro Expires é definido como um horário futuro;
  • 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. Respostas a "assinado" e "não assinado" não compartilham 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 na configuração do Cloud CDN. A resposta veiculada ainda tem os cabeçalhos Cache-Control gerados pelo back-end.

O URL retornado da CLI gcloud 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.

Para instruções sobre o uso de URLs assinados com o Cloud CDN, consulte Usar URLs assinados.

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:

  • para fornecer acesso a vários arquivos restritos;

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

  • para evitar a atualização de URLs sempre que você atualizar a autorização de acesso ao 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 integrados. 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:

  1. criar uma chave de assinatura para o serviço de back-end fornecido;
  2. criar um valor de cookie com o prefixo de URL permitido, a validade, o nome da chave e a assinatura criptográfica;
  3. 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.

Para instruções sobre o uso de cookies assinados com o Cloud CDN, consulte Usar cookies assinados.

Autenticação de origem particular

A autenticação de origem particular concede ao Cloud CDN acesso de longo prazo a buckets particulares do Amazon S3 ou repositórios de objetos compatíveis. O Cloud CDN pode exibir conteúdo dessas origens sem usar o acesso de leitura público.

A autenticação de origem particular é voltada para a origem, enquanto os URLs assinados e os cookies assinados são voltados para o cliente. É possível ativar ambos para o mesmo conteúdo. A autenticação de origem particular limita o acesso não CDN às suas origens e conteúdo. URLs e cookies assinados controlam quais usuários podem acessar o Cloud CDN.

A autenticação de origem particular é compatível com o Cloud CDN com um balanceador de carga de aplicativo externo global ou um balanceador de carga de aplicativo clássico.

Para instruções sobre como usar a autenticação de origem particular com o Cloud CDN, consulte Configurar autenticação de origem particular.

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