Use URLs assinados

Esta página oferece uma vista geral dos URLs assinados e instruções para a respetiva utilização com a RFC do Google Cloud. Os URLs assinados concedem acesso aos recursos por tempo limitado a qualquer pessoa que tenha o URL, quer esta tenha ou não uma Conta Google.

Um URL assinado é um URL que fornece permissão e tempo limitados para fazer um pedido. Os URLs assinados contêm informações de autenticação nas respetivas strings de consulta, o que permite aos utilizadores sem credenciais efetuar ações específicas num recurso. Quando gera um URL assinado, especifica um utilizador ou uma conta de serviço que tem de ter autorização suficiente para fazer o pedido associado ao URL.

Depois de gerar um URL assinado, qualquer pessoa que o possua pode usar o URL assinado para realizar ações específicas (como ler um objeto) num período específico.

Os URLs assinados também suportam um parâmetro URLPrefix opcional, o que lhe permite conceder acesso a vários URLs com base num prefixo comum.

Se quiser restringir o acesso a um prefixo de URL específico, considere usar cookies assinados.

Antes de começar

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

• Certifique-se de que o Cloud CDN está ativado. Para obter instruções, consulte o artigo Usar o Cloud CDN. Pode configurar URLs assinados num back-end antes de ativar o Cloud CDN, mas não têm efeito até o Cloud CDN ser ativado.

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

  gcloud components update
  

Para uma vista geral, consulte o artigo URLs assinados e cookies assinados.

Configure chaves de pedidos assinados

A criação de chaves para os seus URLs assinados ou cookies assinados requer vários passos, que são descritos nas secções seguintes.

Considerações de segurança

A RFC na nuvem não valida os pedidos nas seguintes circunstâncias:

• O pedido não está assinado.
• O serviço de back-end ou o contentor de back-end do pedido não tem o Cloud CDN ativado.

Os pedidos assinados têm de ser sempre validados na origem antes de publicar a resposta. Isto deve-se ao facto de as origens poderem ser usadas para publicar uma combinação de conteúdo assinado e não assinado, e porque um cliente pode aceder diretamente à origem.

• A RFC não bloqueia pedidos sem um parâmetro de consulta Signature ou um cookie HTTP Cloud-CDN-Cookie. Rejeita pedidos com parâmetros de pedidos inválidos (ou com um formato incorreto).
• Quando a sua aplicação deteta uma assinatura inválida, certifique-se de que a aplicação 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 pedidos assinados e não assinados são colocadas em cache separadamente, pelo que uma resposta bem-sucedida a um pedido assinado válido nunca é usada para publicar um pedido não assinado.
• Se a sua aplicação enviar um código de resposta memorizável em cache para um pedido inválido, os pedidos futuros válidos podem ser rejeitados incorretamente.

Para backends do Cloud Storage, certifique-se de que remove o acesso público para que o Cloud Storage possa rejeitar pedidos que não tenham uma assinatura válida.

A tabela seguinte resume o comportamento.

O pedido tem assinatura	Resultado da cache	Comportamento
Não	Não	Encaminhar para a origem do back-end.
Não	Sim	Publicar a partir da cache.
Sim	Não	Validar assinatura. Se for válido, encaminha para a origem do back-end.
Sim	Sim	Validar assinatura. Se for válido, publica a partir da cache.

Crie chaves de pedidos assinados

Ativa o suporte para URLs assinados e cookies assinados do Cloud CDN através da criação de uma ou mais chaves num serviço de back-end, num contentor de back-end ou em ambos ativados para o Cloud CDN.

Para cada serviço de back-end ou contentor de back-end, pode criar e eliminar chaves conforme as suas necessidades de segurança. Cada back-end pode ter até três chaves configuradas em simultâneo. Sugerimos que rode periodicamente as suas chaves eliminando a mais antiga, adicionando uma nova chave e usando a nova chave ao assinar URLs ou cookies.

Pode usar o mesmo nome de chave em vários serviços de back-end e contentores de back-end, porque cada conjunto de chaves é independente dos outros. Os nomes das chaves podem ter até 63 carateres. Para atribuir nomes às chaves, use os carateres A-Z, a-z, 0-9, _ (sublinhado) e - (hífen).

Quando criar chaves, certifique-se de que as mantém seguras, uma vez que qualquer pessoa que tenha uma das suas chaves pode criar URLs assinados ou cookies assinados que o Cloud CDN aceita até que a chave seja eliminada do Cloud CDN. As chaves são armazenadas no computador onde gera os URLs assinados ou os cookies assinados. A RFC na nuvem também armazena as chaves para validar as assinaturas de pedidos.

Para manter as chaves secretas, os valores das chaves não são incluídos nas respostas a pedidos da API. Se perder uma chave, tem de criar uma nova.

Para criar uma chave de pedido assinada, siga estes passos.