Autentique conteúdo

A RFC oferece três formas de ajudar a controlar o acesso ao seu conteúdo em cache:

  • Os URLs assinados permitem-lhe publicar respostas a partir das caches distribuídas globalmente da Google Cloudquando precisa que os pedidos sejam autorizados. Qualquer pessoa com o URL assinado pode aceder ao recurso durante um período limitado.
  • Os cookies assinados também lhe permitem aceder a um recurso durante um período limitado. São úteis quando precisa de assinar dezenas ou centenas de URLs para cada utilizador.
  • A autenticação de origem privada permite-lhe limitar as ligações aos contentores do Amazon Simple Storage Service (Amazon S3) ou a outros armazenamentos de objetos compatíveis e impedir que os utilizadores acedam diretamente aos mesmos.

URLs assinados

Um URL assinado é um URL que fornece permissão e tempo limitados para fazer um pedido.

Exemplos de utilização

Em alguns cenários, pode não querer exigir que os utilizadores tenham uma Conta Google para aceder ao conteúdo da CDN do Google Cloud, mas ainda quer controlar o acesso através da lógica específica da sua aplicação.

A forma habitual de abordar este exemplo de utilização é fornecer um URL assinado a um utilizador, o que lhe dá acesso de leitura a esse recurso durante um período limitado. Especifica um tempo de expiração quando cria o URL assinado. Qualquer pessoa que conheça o URL pode aceder ao recurso até atingir o prazo de validade do URL ou até que a chave usada para assinar o URL seja alterada.

Use URLs assinados nos seguintes casos:

  • Para restringir o acesso a ficheiros individuais, como uma instalação de transferência.

  • Para publicar anúncios para utilizadores com aplicações cliente que não suportam cookies.

Como funcionam os URLs assinados

Os URLs assinados dão a um cliente acesso temporário a um recurso privado sem exigir autorização adicional. Para tal, os elementos selecionados de um pedido são processados com hash e assinados criptograficamente através de uma chave fortemente aleatória que gera.

Quando um pedido usa o URL assinado que forneceu, o pedido é considerado autorizado a receber o conteúdo pedido. Quando o Cloud CDN recebe um pedido com uma assinatura inválida para um serviço ativado, o pedido é rejeitado e nunca é enviado para o seu back-end para processamento.

Geralmente, um URL assinado pode ser usado por qualquer pessoa que o tenha. No entanto, um URL assinado destina-se normalmente a ser usado apenas pelo cliente ao qual o URL foi fornecido. Para mitigar o risco de o URL ser usado por um cliente diferente, os URLs assinados expiram no momento escolhido por si. Para minimizar o risco de um URL assinado ser partilhado, defina a respetiva expiração o mais rapidamente possível.

Como são assinados os URLs

Antes de poder assinar URLs, cria uma ou mais chaves criptográficas num serviço de back-end, num contentor de back-end ou em ambos. Em seguida, assina e aplica hash criptográfico a um URL através da Google Cloud CLI ou do seu próprio código.

Processamento de URLs assinados

Quando o processamento de URLs assinados está ativado num back-end, o Cloud CDN dá um tratamento especial aos pedidos com URLs assinados. Especificamente, os pedidos com um parâmetro de consulta Signature são considerados assinados. Quando recebe um pedido deste tipo, a RFC de nuvem valida o seguinte:

  • O método HTTP é GET, HEAD, OPTIONS ou TRACE.
  • O parâmetro Expires está definido para uma hora no futuro.
  • A assinatura do pedido corresponde à assinatura calculada através da chave com nome.

Se alguma destas verificações falhar, é publicado um anúncio de resposta 403 Forbidden. Caso contrário, o pedido é encaminhado para o back-end ou publicado a partir da cache. Os pedidos OPTIONS e TRACE são sempre encaminhados para o back-end diretamente e não são publicados a partir da cache. Todos os pedidos assinados válidos para um URL de base específico (a parte antes do parâmetro Expires) partilham a mesma entrada de cache. As respostas a pedidos assinados e não assinados não partilham entradas de cache. As respostas são colocadas em cache e publicadas até à hora de expiração que definir.

O conteúdo que requer pedidos assinados é frequentemente marcado como não armazenável em cache através do cabeçalho Cache-Control. Para tornar esses objetos compatíveis com o Cloud CDN sem exigir alterações no back-end, o Cloud CDN substitui o cabeçalho Cache-Control quando responde a pedidos que têm URLs assinados válidos. O Cloud CDN trata o conteúdo como memorizável em cache e usa o parâmetro max-age definido na sua configuração do Cloud CDN. A resposta publicada continua a ter os cabeçalhos Cache-Control que o back-end gerou.

O URL devolvido pela CLI gcloud ou produzido pelo seu código personalizado pode ser distribuído de acordo com as suas necessidades. Recomendamos que assine apenas URLs HTTPS, porque o HTTPS oferece um transporte seguro que impede a interceção do componente de assinatura do URL assinado. Da mesma forma, deve distribuir os URLs assinados através de protocolos de transporte seguros, como TLS/HTTPS.

Para obter instruções sobre como usar URLs assinados com a RFC na nuvem, consulte o artigo Use URLs assinados.

Cookies assinados

Um cookie assinado é um cookie que concede autorização e tempo limitados para fazer pedidos de um conjunto de ficheiros.

Exemplos de utilização

Use cookies assinados nos seguintes casos:

  • Para conceder acesso a vários ficheiros restritos.

  • Para evitar alterar os seus URLs atuais.

  • Para evitar a atualização dos URLs sempre que atualizar a autorização para aceder ao conteúdo.

Streaming de conteúdo multimédia através de HLS e DASH

Se publicar conteúdo de vídeo e áudio através dos protocolos HTTP Live Streaming (HLS) ou Dynamic Adaptive Streaming over HTTP (DASH), normalmente, gera um manifesto que contém uma lista de URLs para segmentos de vídeo e áudio. Pode ter várias instâncias de cada segmento para fornecer codificações diferentes (códec, taxa de bits, resolução) a um cliente.

Embora possa usar os URLs assinados da RFC para assinar e autorizar o acesso a cada um destes URLs, a geração dinâmica de todas as combinações possíveis por utilizador é complexa e aumenta a carga de origem e a complexidade da aplicação.

Os cookies assinados foram criados para resolver este problema. Pode fornecer ao utilizador um cookie assinado que o autoriza a aceder a qualquer conteúdo que corresponda a uma política (prefixo do URL e data de validade) sem ter de gerar ou assinar individualmente os seus manifestos de multimédia. Pode atualizar o acesso do utilizador periodicamente através da API JavaScript fetch() na navegação na página ou noutros mecanismos em segundo plano nas aplicações incorporadas. A capacidade de atualizar o acesso dos utilizadores também lhe permite usar prazos de validade curtos, o que dificulta a partilha de conteúdo protegido por parte dos utilizadores.

Pode emitir estes cookies para utilizadores com vários clientes de navegador e outros clientes que usam HTTP, como o ExoPlayer da Google e o AVPlayer do iOS.

Transferências binárias (videojogos)

Semelhante ao streaming de multimédia, se fornecer transferências de clientes de jogos, pode dividir grandes patches ou dados de jogos de vários gigabytes em partes mais pequenas para suportar o armazenamento em cache, a invalidação e a simultaneidade mais detalhados.

Normalmente, estes fragmentos são apresentados numa lista. Os cookies assinados permitem-lhe autorizar o acesso a essas transferências apenas a utilizadores autenticados sem exigir modificações ao manifesto e (tal como com os URLs assinados) sem renunciar às vantagens do armazenamento em cache da CDN da Google Cloud.

Como funcionam os cookies assinados

A configuração e a emissão de cookies assinados requerem três passos:

  1. Crie uma chave de assinatura para o serviço de back-end especificado.
  2. Crie um valor de cookie com o prefixo de URL permitido, a data de validade, o nome da chave e a assinatura criptográfica.
  3. Emita o cookie no código da sua aplicação.

A RFC valida estes cookies assinados quando são incluídos com os pedidos.

Pode impedir que os utilizadores contornem os controlos de cookies assinados quando usam um contentor do Cloud Storage. Para tal, restrinja o acesso ao contentor subjacente removendo a função allUsers e concedendo à conta de serviço do Cloud CDN acesso de leitura ao contentor.

Da mesma forma, as instâncias de máquinas virtuais (VM) devem validar as assinaturas em todos os pedidos assinados que publicam.

Para obter instruções sobre como usar cookies assinados com o Cloud CDN, consulte o artigo Usar cookies assinados.

Autenticação de origem privada

A autenticação de origem privada dá ao RFC na nuvem acesso a longo prazo a contentores privados do Amazon S3 ou a armazenamentos de objetos compatíveis. Em seguida, a CDN na nuvem pode publicar conteúdo a partir destas origens sem usar o acesso de leitura público.

A autenticação de origem privada é orientada para a origem, enquanto os URLs assinados e os cookies assinados são orientados para o cliente. Pode ativar ambas as opções para o mesmo conteúdo. A autenticação de origem privada limita o acesso que não é da RFC às suas origens e conteúdo. Os URLs assinados e os cookies controlam que utilizadores podem aceder ao Cloud CDN.

A autenticação de origem privada é suportada para o Cloud CDN com um balanceador de carga de aplicações externo global ou um balanceador de carga de aplicações clássico.

Para obter instruções sobre como usar a autenticação de origem privada com o Cloud CDN, consulte o artigo Configure a autenticação de origem privada.

Advertências e limitações

  • É o único responsável por qualquer conformidade com o consentimento e a privacidade necessária para os seus cookies assinados. Os cookies assinados são emitidos e geridos por si e não pela Google.

  • Se usar URLs assinados e cookies assinados para controlar o acesso aos mesmos ficheiros, e um visitante usar um URL assinado para pedir um ficheiro, a CDN da Google Cloud determina se deve devolver o ficheiro ao visitante apenas com base no URL assinado. A RFC de multimédia na nuvem só considera cookies assinados se o URL não estiver assinado.

  • Se configurou o seu serviço para pedidos assinados e o seu URL inclui Signature como um parâmetro de consulta, o Cloud CDN tenta interpretar o seu URL como um URL assinado. Se a RFC tentar tratar o seu URL como um URL assinado quando não era essa a sua intenção, é provável que o URL não seja um URL assinado válido, pelo que a RFC o rejeita.

  • Normalmente, os navegadores e outros clientes aplicam limites ao tamanho dos cookies (4 KB por cookie) e um total de 50 por domínio, conforme a RFC 6265. Considere a carga útil total de cookies enviada a partir do respetivo domínio.

  • Aplicam-se limites e restrições da RFC na nuvem, incluindo um máximo de três chaves de pedidos assinados por back-end.

  • Os pedidos assinados não são cobrados de forma diferente dos pedidos existentes do Cloud CDN. No entanto, os pedidos com falhas (rejeitados), como os que têm assinaturas expiradas ou inválidas, continuam a incorrer em custos de pesquisa na cache.

O que se segue?