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.

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.

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

Configure as autorizações do Cloud Storage

Se usar o Cloud Storage e tiver restringido quem pode ler os objetos, tem de conceder autorização ao Cloud CDN para ler os objetos adicionando a conta de serviço do Cloud CDN às ACLs do Cloud Storage.

Não precisa de criar a conta de serviço. A conta de serviço é criada automaticamente na primeira vez que adiciona uma chave a um contentor de back-end num projeto.

Antes de executar o seguinte comando, adicione, pelo menos, uma chave a um contentor de back-end no seu projeto. Caso contrário, o comando falha com um erro porque a conta de serviço de preenchimento da cache da RFC na nuvem não é criada até adicionar 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 seu projeto e BUCKET pelo seu contentor de armazenamento.

A conta de serviço do Cloud CDN service-PROJECT_NUMBER@cloud-cdn-fill.iam.gserviceaccount.com não aparece na lista de contas de serviço no seu projeto. Isto acontece porque a conta de serviço do Cloud CDN é propriedade do Cloud CDN e não do seu projeto.

Para mais informações sobre os números dos projetos, consulte o artigo Localize o ID do projeto e o número do projeto na Google Cloud documentação de ajuda da consola.

Personalize o tempo máximo da cache

A RFC na nuvem armazena em cache as respostas a pedidos assinados, independentemente do cabeçalho Cache-Control do back-end. O tempo máximo durante o qual as respostas podem ser colocadas em cache sem revalidação é definido pela flag signed-url-cache-max-age, que tem um valor predefinido de uma hora e pode ser modificada, conforme mostrado aqui.

Para definir o tempo máximo da cache para um serviço de back-end ou um contentor 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

Liste os nomes das chaves de pedidos assinados

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

gcloud compute backend-services describe BACKEND_NAME

gcloud compute backend-buckets describe BACKEND_NAME

Elimine chaves de pedidos assinados

Quando os URLs assinados por uma determinada chave já não devem ser respeitados, execute um dos seguintes comandos para eliminar essa chave do serviço de back-end ou do contentor 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

Assine URLs

O último passo é assinar os URLs e distribuí-los. Pode assinar URLs através do comando gcloud compute sign-url ou através de código escrito por si. Se precisar de muitos URLs assinados, o código personalizado oferece um melhor desempenho.

Crie URLs assinados

Siga estas instruções para criar URLs assinados através do comando gcloud compute sign-url. Este passo pressupõe que já criou as chaves.

gcloud compute sign-url \
  "URL" \
  --key-name KEY_NAME \
  --key-file KEY_FILE_NAME \
  --expires-in TIME_UNTIL_EXPIRATION \
  [--validate]

gcloud compute sign-url \
  "https://example.com/media/video.mp4" \
  --key-name my-test-key \
  --expires-in 30m \
  --key-file sign-url-key-file

Crie URLs assinados de forma programática

Os seguintes exemplos de código demonstram como criar URLs assinados programaticamente.

import (
	"crypto/hmac"
	"crypto/sha1"
	"encoding/base64"
	"fmt"
	"io"
	"io/ioutil"
	"os"
	"strings"
	"time"
)

// SignURL creates a signed URL for an endpoint on Cloud CDN.
//
// - url must start with "https://" and should not have the "Expires", "KeyName", or "Signature"
// query parameters.
// - key should be in raw form (not base64url-encoded) which is 16-bytes long.
// - keyName must match a key added to the backend service or bucket.
func signURL(url, keyName string, key []byte, expiration time.Time) string {
	sep := "?"
	if strings.Contains(url, "?") {
		sep = "&"
	}
	url += sep
	url += fmt.Sprintf("Expires=%d", expiration.Unix())
	url += fmt