Usar cookies assinados

Esta página fornece uma visão geral dos cookies assinados e das instruções para usá-los com o Cloud CDN. Os cookies assinados dão acesso a recursos por tempo limitado a um conjunto de arquivos, ainda que os usuários não tenham Contas do Google.

Os cookies assinados são uma alternativa aos URLs assinados. Eles protegem o acesso ao assinar dezenas ou centenas de URLs separadamente para cada usuário no aplicativo.

Os cookies assinados permitem o seguinte:

• autorizar um usuário e fornecer a ele um token por tempo limitado para acessar seu conteúdo protegido (em vez de assinar cada URL);
• analisar o acesso do usuário para um prefixo de URL específico, como https://media.example.com/videos/, e conceder ao usuário autorizado acesso ao conteúdo protegido somente nesse prefixo de URL;
• manter seus URLs e manifestos de mídia inalterados, simplificando o pipeline de empacotamento e melhorando o armazenamento em cache.

Se você quiser definir o acesso a URLs específicos em vez disso, considere usar URLs assinados.

Antes de começar

Antes de usar cookies assinados, faça o seguinte:

• Verifique se o Cloud CDN está ativado. Para instruções, consulte Como usar o Cloud CDN. É possível configurar cookies assinados em um back-end antes de ativar o Cloud CDN, mas isso não terá efeito até que o Cloud CDN seja ativado.

• Se necessário, atualize para a versão mais recente da CLI do Google Cloud:

  gcloud components update
  

Para uma visão geral, consulte URLs e cookies assinados.

Como configurar chaves de solicitação assinadas

A criação de chaves para seus URLs ou cookies assinados requer vários passos, descritos nas seções a seguir.

Considerações sobre segurança

O Cloud CDN não valida solicitações nas seguintes circunstâncias:

• A solicitação não está assinada.
• O serviço de back-end ou o bucket de back-end da solicitação não tem o Cloud CDN ativado.

As solicitações assinadas sempre precisam ser validadas na origem antes de exibir a resposta. Isso ocorre porque as origens podem ser usadas para exibir uma mistura de conteúdo assinado e não assinado e porque um cliente pode acessar a origem diretamente.

• O Cloud CDN não bloqueia solicitações sem um parâmetro de consulta Signature ou um cookie HTTP Cloud-CDN-Cookie. Ele rejeita as solicitações com parâmetros de solicitação inválidos (ou com outros tipos de erros).
• Quando o aplicativo detectar uma assinatura inválida, verifique se ele responde com um código de resposta HTTP 403 (Unauthorized). Os códigos de resposta HTTP 403 não são armazenáveis em cache.
• As respostas a solicitações assinadas e não assinadas são armazenadas em cache separadamente. Dessa maneira, uma resposta bem-sucedida a uma solicitação assinada válida nunca é usada para atender a uma solicitação não assinada.
• Se o aplicativo enviar um código de resposta armazenável em cache para uma solicitação inválida, as futuras solicitações válidas poderão ser rejeitadas incorretamente.

No caso dos back-ends do Cloud Storage, certifique-se de remover o acesso público para que o Cloud Storage possa rejeitar solicitações que não tenham uma assinatura válida.

A tabela a seguir resume o comportamento.

Criar chaves de solicitação assinadas

Para ativar o suporte a URLs e cookies assinados do Cloud CDN, crie uma ou mais chaves em um serviço de back-end com Cloud CDN ativado, um bucket de back-end ou ambos.

Para cada serviço de back-end ou bucket de back-end, é possível criar e excluir chaves, conforme as necessidades de segurança. Cada back-end pode ter até três chaves configuradas de cada vez. Sugerimos rotacionar periodicamente suas chaves excluindo a mais antiga, adicionando uma nova e usando-a ao assinar URLs ou cookies.

É possível usar o mesmo nome de chave em vários serviços e buckets de back-end, porque cada conjunto de chaves é independente dos outros. Os nomes das chaves podem ter até 63 caracteres. Para nomear as chaves, use os caracteres de A-Z, a-z, 0-9, _ (sublinhado) e - (hífen).

Ao criar chaves, certifique-se de mantê-las seguras, porque qualquer pessoa que tenha uma das chaves pode criar URLs ou cookies assinados aceitos pelo Cloud CDN até que a chave seja excluída. As chaves são armazenadas no computador em que os URLs ou cookies assinados são gerados. O Cloud CDN também armazena as chaves para verificar as assinaturas das solicitações.

Para manter as chaves em segredo, os valores de chave não são incluídos nas respostas a solicitações de API. Se você perder uma chave, será necessário criar uma nova.

Para criar uma chave de solicitação assinada, siga estas etapas.

head -c 16 /dev/urandom | base64 | tr +/ -_ > KEY_FILE_NAME

gcloud compute backend-services \
   add-signed-url-key BACKEND_NAME \
   --key-name KEY_NAME \
   --key-file KEY_FILE_NAME

gcloud compute backend-buckets \
   add-signed-url-key BACKEND_NAME \
   --key-name KEY_NAME \
   --key-file KEY_FILE_NAME

Configurar permissões do Cloud Storage

Se você usar o Cloud Storage e tiver restringido quem pode ler os objetos, deverá conceder permissão ao Cloud CDN para ler os objetos ao adicionar a conta de serviço do Cloud CDN às ACLs do Cloud Storage.

Não é necessário criar a conta de serviço. A conta de serviço é criada automaticamente na primeira vez que uma chave é adicionada a um bucket de back-end em um projeto.

Antes de executar o comando a seguir, adicione pelo menos uma chave a um bucket de back-end no projeto. Caso contrário, o comando falhará com um erro, já que a conta de serviço de preenchimento de cache do Cloud CDN não será criada até que sejam adicionadas uma ou mais chaves para o projeto.

gcloud storage buckets add-iam-policy-binding gs://BUCKET \
  --member=serviceAccount:service-PROJECT_NUMBER@cloud-cdn-fill.iam.gserviceaccount.com \
  --role=roles/storage.objectViewer

Substitua PROJECT_NUMBER pelo número do projeto e BUCKET pelo bucket de armazenamento.

A conta de serviço service-PROJECT_NUMBER@cloud-cdn-fill.iam.gserviceaccount.com do Cloud CDN não consta da lista de contas de serviço do projeto. Isso acontece porque a conta de serviço do Cloud CDN pertence ao Cloud CDN, não ao projeto.

Para mais informações sobre números de projeto, consulte Localizar o ID do projeto e o número do projeto na documentação de Ajuda do console do Google Cloud .

Personalizar o tempo máximo de cache

O Cloud CDN armazena em cache as respostas para solicitações assinadas, independentemente do cabeçalho Cache-Control do back-end. O tempo máximo em que as respostas podem ser armazenadas em cache sem revalidação é definido pela sinalização signed-url-cache-max-age, que tem como padrão uma hora e pode ser modificada conforme mostrado aqui.

Para definir o tempo máximo de cache para um serviço de back-end ou um bucket de back-end, execute um dos seguintes comandos:

gcloud compute backend-services update BACKEND_NAME
  --signed-url-cache-max-age MAX_AGE

gcloud compute backend-buckets update BACKEND_NAME
  --signed-url-cache-max-age MAX_AGE

Listar os nomes das chaves de solicitação assinadas

Para listar as chaves em um serviço de back-end ou bucket de back-end, execute um dos seguintes comandos:

gcloud compute backend-services describe BACKEND_NAME

gcloud compute backend-buckets describe BACKEND_NAME

Excluir chaves de solicitação assinadas

Quando os URLs assinados por uma chave específica não forem mais aceitos, execute um dos seguintes comandos para excluir esta chave do serviço de back-end ou do bucket de back-end:

gcloud compute backend-services \
   delete-signed-url-key BACKEND_NAME --key-name KEY_NAME

gcloud compute backend-buckets \
   delete-signed-url-key BACKEND_NAME --key-name KEY_NAME

Como criar uma política

As políticas de cookies assinados são uma série de pares key-value, delimitados pelo caractere :, parecida com os parâmetros de consulta usados em um URL assinado. Para exemplos, consulte Como emitir cookies para usuários.

As políticas representam os parâmetros para os quais uma solicitação é válida. Elas são assinadas usando um código de autenticação de mensagem baseado em hash (HMAC, na sigla em inglês), que o Cloud CDN valida em cada solicitação.

Como definir campos e formato da política

Há quatro campos obrigatórios que você precisa definir na seguinte ordem:

• URLPrefix
• Expires
• KeyName
• Signature

Os pares key-value em uma política de cookies assinados diferenciam maiúsculas de minúsculas.

URLPrefix

URLPrefix indica um prefixo de URL codificado em base64 e seguro que abrange todos os caminhos para os quais a assinatura deve ser válida.

Um URLPrefix codifica um esquema (http:// ou https://), um Nome de domínio totalmente qualificado (FQDN, na sigla em inglês) e um caminho opcional. Encerrar o caminho com um / é opcional, mas recomendado. O prefixo não pode incluir parâmetros de consulta ou fragmentos como ? ou #.

Por exemplo, https://media.example.com/videos corresponde a solicitações para os seguintes itens:

• https://media.example.com/videos?video_id=138183&user_id=138138
• https://media.example.com/videos/137138595?quality=low

O caminho do prefixo é usado como uma substring de texto, não estritamente como um caminho de diretório. Por exemplo, o prefixo https://example.com/data concede acesso aos dois itens a seguir:

• /data/file1
• /database

Para evitar esse erro, recomendamos encerrar todos os prefixos com /, a menos que você opte intencionalmente por encerrar o prefixo com um nome de arquivo parcial, como https://media.example.com/videos/123, para conceder acesso ao seguinte:

• /videos/123_chunk1
• /videos/123_chunk2
• /videos/123_chunkN

Se o URL solicitado não corresponder a URLPrefix, o Cloud CDN rejeitará a solicitação e retornará um erro HTTP 403 ao cliente.

Expires

Expires precisa ser um carimbo de data/hora Unix (o número de segundos desde 1º de janeiro de 1970).

KeyName

KeyName é o nome da chave criada para o bucket de back-end ou serviço de back-end. Os nomes das chaves diferenciam maiúsculas de minúsculas.

Signature

Signature é a assinatura HMAC-SHA-1 segura para URL e codificada em Base64 dos campos que compõem a política de cookies. Isso é validado em cada solicitação. As solicitações com uma assinatura inválida são rejeitadas com um erro HTTP 403.

Como criar cookies assinados de maneira programática

Os exemplos de código a seguir demonstram como criar cookies assinados de maneira programática.

import (
	"crypto/hmac"
	"crypto/sha1"
	"encoding/base64"
	"fmt"
	"io"
	"io/ioutil"