Utilizzare i cookie firmati

Questa pagina fornisce una panoramica dei cookie firmati e le istruzioni per utilizzarli con Cloud CDN. I cookie firmati consentono di accedere a una serie di file a tempo limitato, indipendentemente dal fatto che gli utenti dispongano di un Account Google.

I cookie firmati rappresentano un'alternativa agli URL firmati. I cookie firmati proteggono l'accesso se la firma separata di centinaia o URL per ciascun utente non è possibile nella tua applicazione.

I cookie firmati ti consentono di:

• Autorizza un utente e forniscigli un token a tempo limitato per accedere ai contenuti protetti (anziché firmare ogni URL).
• Limita l'accesso dell'utente a un prefisso URL specifico, ad esempio https://media.example.com/videos/, e concedi all'utente autorizzato l'accesso solo ai contenuti protetti all'interno di quel prefisso URL.
• Mantieni invariati gli URL e i manifest multimediali, semplificando la pipeline di confezionamento e migliorando la memorizzazione nella cache.

Se vuoi invece limitare l'accesso a URL specifici, valuta la possibilità di utilizzare gli URL firmati.

Prima di iniziare

Prima di utilizzare i cookie firmati, procedi nel seguente modo:

• Assicurati che Cloud CDN sia abilitato; per le istruzioni, consulta la pagina relativa all'utilizzo di Cloud CDN. Puoi configurare i cookie firmati su un backend prima di abilitare Cloud CDN, ma non avrà alcun effetto finché Cloud CDN non verrà abilitato.

• Se necessario, esegui l'aggiornamento all'ultima versione di Google Cloud CLI:

  gcloud components update
  

Per una panoramica, vedi URL firmati e cookie firmati.

Configurazione delle chiavi di richiesta firmate

La creazione di chiavi per gli URL firmati o per i cookie firmati richiede diversi passaggi, descritti nelle sezioni seguenti.

Considerazioni sulla sicurezza

Importante: devi configurare i server web di origine per convalidare le firme per ogni richiesta firmata che vengono pubblicate e accettare o rifiutare le richieste non firmate.

Cloud CDN non convalida le richieste nelle seguenti circostanze:

• La richiesta non è stata firmata.
• Cloud CDN non è abilitato per il servizio di backend o il bucket di backend per la richiesta.

Le richieste firmate devono essere sempre convalidate nell'origine prima di pubblicare la risposta. Ciò si verifica perché le origini possono essere utilizzate per pubblicare una combinazione di contenuti firmati e non firmati e perché un client potrebbe accedere direttamente all'origine.

• Cloud CDN non blocca le richieste senza un parametro di ricerca Signature o un cookie HTTP Cloud-CDN-Cookie. Rifiuta le richieste con parametri di richiesta non validi (o altrimenti non validi).
• Quando la tua applicazione rileva una firma non valida, assicurati che risponda con un codice di risposta HTTP 403 (Unauthorized). HTTP 403 codici di risposta non possono essere memorizzati nella cache.
• Le risposte alle richieste firmate e non firmate vengono memorizzate separatamente nella cache, quindi una risposta corretta a una richiesta firmata non viene mai utilizzata per gestire una richiesta non firmata.
• Se la tua applicazione invia un codice di risposta memorizzabile nella cache a una richiesta non valida, le richieste future valide potrebbero essere rifiutate in modo errato.

Per i backend di Cloud Storage, assicurati di rimuovere l'accesso pubblico, in modo che Cloud Storage possa rifiutare le richieste senza una firma valida.

La tabella riportata di seguito riassume il comportamento.

La richiesta contiene una firma	Hit cache	Comportamento
No	No	Inoltra a origine del backend.
No	Sì	Pubblica dalla cache.
Sì	No	Convalida firma. Se valido, inoltra all'origine del backend.
Sì	Sì	Convalida firma. Se valido, servi dalla cache.

Crea chiavi di richiesta firmate

Attivi il supporto per gli URL firmati e i cookie firmati di Cloud CDN creando una o più chiavi in un servizio di backend, un bucket di backend abilitato per Cloud CDN o entrambi.

Per ogni servizio di backend o bucket di backend puoi creare ed eliminare chiavi in base alle esigenze di sicurezza. Ogni backend può avere configurato fino a tre chiavi alla volta. Ti suggeriamo di ruotare periodicamente le chiavi eliminando le meno recenti, aggiungendone una nuova e utilizzando la nuova chiave quando firmi URL o cookie.

Puoi utilizzare lo stesso nome di chiave in più servizi e bucket di backend perché ogni set di chiavi è indipendente dagli altri. I nomi delle chiavi possono contenere fino a 63 caratteri. Per assegnare un nome alle chiavi, utilizza i caratteri A-Z, a-z, 0-9, _ (trattino basso) e - (trattino).

Quando crei le chiavi, assicurati di tenerle al sicuro perché chiunque abbia una delle tue chiavi può creare URL firmati o cookie firmati che Cloud CDN accetta finché la chiave non viene eliminata da Cloud CDN. Le chiavi vengono memorizzate sul computer in cui generi gli URL firmati o i cookie firmati. Cloud CDN archivia anche le chiavi per verificare le firme delle richieste.

Per mantenere segrete le chiavi, i valori delle chiavi non sono inclusi nelle risposte alle richieste API. Se perdi una chiave, devi crearne una nuova.

Importante: mantieni privato il file della chiave generato e non esporlo agli utenti, né archiviarlo direttamente nel codice sorgente. Valuta la possibilità di utilizzare un meccanismo di archiviazione dei secret come Cloud Key Management Service per criptare la chiave e fornire l'accesso solo alle applicazioni attendibili.

Per creare una chiave di richiesta firmata, segui questi passaggi.

Console

1. Nella console Google Cloud, vai alla pagina Cloud CDN.

   Vai a Cloud CDN

2. Fai clic sul nome dell'origine a cui vuoi aggiungere la chiave.
3. Nella pagina Dettagli origine, fai clic sul pulsante Modifica.
4. Nella sezione Nozioni di base sull'origine, fai clic su Avanti per aprire la sezione Regole host e percorso.
5. Nella sezione Regole host e percorso, fai clic su Avanti per aprire la sezione Rendimento cache.
6. Nella sezione Contenuti con limitazioni, seleziona Limita l'accesso utilizzando gli URL firmati e i cookie firmati.

7. Fai clic su Aggiungi chiave di firma.

   1. Specifica un nome univoco per la nuova chiave di firma.

   2. Nella sezione Metodo di creazione della chiave, seleziona Genera automaticamente. In alternativa, fai clic su Fammi entrare, quindi specifica un valore chiave di firma.

      Nella prima opzione, copia la coppia chiave-valore di generazione automatica in un file privato, che puoi utilizzare per creare URL firmati.

   3. Fai clic su Fine.

   4. Nella sezione Età massima voce voce cache, inserisci un valore, quindi seleziona un'unità di tempo.

8. Fai clic su Fine.

gcloud

Lo strumento a riga di comando gcloud legge le chiavi da un file locale da te specificato. Il file della chiave deve essere creato generando 128 bit molto casuali, codificandoli con Base64 e sostituendo il carattere + con - e sostituendo il carattere / con _. Per ulteriori informazioni, consulta RFC 4648. È fondamentale che la chiave sia assolutamente casuale. In un sistema simile a UNIX, puoi generare una chiave fortemente casuale e archiviarla nel file della chiave con il seguente comando:

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

Per aggiungere la chiave a un servizio di backend:

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

Per aggiungere la chiave a un bucket di backend:

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

Nota: anche se il sottocomando è add-signed-url-key, la chiave è una chiave di richiesta firmata che funziona sia per i cookie firmati sia per gli URL firmati.

Configura le autorizzazioni per Cloud Storage

Se utilizzi Cloud Storage e hai limitato gli utenti che possono leggere gli oggetti, devi concedere a Cloud CDN l'autorizzazione a leggere gli oggetti aggiungendo l'account di servizio Cloud CDN agli ACL di Cloud Storage.

Non è necessario creare l'account di servizio. L'account di servizio viene creato automaticamente la prima volta che aggiungi una chiave a un bucket di backend in un progetto.

Prima di eseguire il comando seguente, aggiungi almeno una chiave a un bucket di backend nel progetto. In caso contrario, il comando non riesce e viene restituito un errore perché l'account di servizio di riempimento della cache Cloud CDN non viene creato finché non si aggiungono una o più chiavi per il progetto. Sostituisci PROJECT_NUM con il numero del progetto e BUCKET con il bucket di archiviazione.

Nota: se nel progetto è presente un criterio di condivisione del dominio (DRS) con dominio, devi disabilitarlo prima di eseguire il comando gsutil iam ch. Assicurati di riattivare il criterio dopo aver eseguito il comando gsutil iam ch.

gsutil iam ch \
  serviceAccount:[e-mail]:objectViewer \
  gs://BUCKET

L'account di servizio Cloud CDN [e-mail] non viene visualizzato nell'elenco degli account di servizio nel progetto. Questo perché l'account di servizio Cloud CDN è di proprietà di Cloud CDN, non il tuo progetto.

Per ulteriori informazioni sui numeri di progetto, consulta Individuare l'ID e il numero del progetto nella documentazione della guida di Google Cloud Console.

Personalizzare il tempo massimo della cache

Cloud CDN memorizza nella cache le risposte per le richieste firmate a prescindere dall'intestazione Cache-Control del backend. Il tempo massimo in cui le risposte possono essere memorizzate nella cache senza riconvalida è impostato dal flag signed-url-cache-max-age, che per impostazione predefinita è di un'ora e può essere modificato come mostrato qui.

Per impostare la durata massima della cache per un servizio o un bucket di backend, esegui uno dei seguenti comandi:

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

Elenca i nomi delle chiavi di richiesta firmati

Per elencare le chiavi su un servizio o bucket di backend, esegui uno dei seguenti comandi:

gcloud compute backend-services describe BACKEND_NAME

gcloud compute backend-buckets describe BACKEND_NAME

Elimina chiavi di richiesta firmate

Quando gli URL firmati da una determinata chiave non devono più essere rispettati, esegui uno dei seguenti comandi per eliminare la chiave dal servizio di backend o dal bucket di backend:

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

Creazione di un criterio

I criteri relativi ai cookie firmati sono una serie di key-value coppie (delimitati dal carattere :), simili ai parametri di ricerca utilizzati in un URL firmato. Per alcuni esempi, vedi Rilascio di cookie per gli utenti.

I criteri rappresentano i parametri per i quali è valida una richiesta. I criteri vengono firmati utilizzando un codice HMAC (Hash-based Message Authentication Code) che Cloud CDN convalida su ogni richiesta.

Definizione del formato dei criteri e dei campi

Esistono quattro campi obbligatori che devi definire nel seguente ordine:

• URLPrefix
• Expires
• KeyName
• Signature

Le coppie key-value in un criterio relativo ai cookie firmati sono sensibili alle maiuscole.

Prefisso URL

URLPrefix indica un prefisso URL con codifica Base64 sicuro per l'URL che include tutti i percorsi per cui la firma deve essere valida.

Un URLPrefix codifica uno schema (http:// o https://), un nome di dominio completo e un percorso facoltativo. Terminare il percorso con / è facoltativo ma consigliato. Il prefisso non deve includere parametri di ricerca o frammenti come ? o #.

Ad esempio, https://media.example.com/videos associa le richieste a entrambi i seguenti casi:

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

Il percorso del prefisso viene utilizzato come sottostringa di testo, non rigorosamente come percorso della directory. Ad esempio, il prefisso https://example.com/data concede l'accesso a entrambi i seguenti elementi:

• /data/file1
• /database

Per evitare questo errore, consigliamo di terminare tutti i prefissi con /, a meno che tu non scelga intenzionalmente di terminare il prefisso con un nome file parziale, ad esempio https://media.example.com/videos/123, per concedere l'accesso ai seguenti elementi:

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

Se l'URL richiesto non corrisponde a URLPrefix, Cloud CDN rifiuta la richiesta e restituisce un errore HTTP 403 al client.

Scadenza

Expires deve essere un timestamp Unix (il numero di secondi dal 1° gennaio 1970).

NomeChiave

KeyName è il nome della chiave creata per un bucket di backend o un servizio di backend. I nomi delle chiavi sono sensibili alle maiuscole.

Firma

Signature è la firma HMAC-SHA-1 codificata in base64 con protezione dell'URL dei campi che compongono il criterio dei cookie. Questa operazione viene convalidata per ogni richiesta; le richieste con una firma non valida vengono rifiutate con un errore HTTP 403.

Creazione di cookie firmati in modo programmatico

I seguenti esempi di codice mostrano come creare in modo programmatico i cookie firmati.

Nota: valuta l'utilizzo di Secret Manager per la gestione dell'accesso alle chiavi di firma.

Nota: i componenti host e percorso di URLPrefix vengono utilizzati per convalidare le firme. Quando fornisci URLPrefix alle API di pubblicità programmatica, ometti la porta. In altre parole, per un percorso come https://example.com:443/path/, specifica il percorso come https://example.com/path/. In caso contrario, la firma generata non corrisponderà al valore calcolato da Cloud CDN.

Go

Visualizza su GitHub Feedback

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

// signCookie creates a signed cookie for an endpoint served by Cloud CDN.
//
// - urlPrefix must start with "https://" and should include the path prefix
// for which the cookie will authorize access to.
// - 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 signCookie(urlPrefix, keyName string, key []byte, expiration time.Time) (string, error) {
	encodedURLPrefix := base64.URLEncoding.EncodeToString([]byte(urlPrefix))
	input := fmt.Sprintf("URLPrefix=%s:Expires=%d:KeyName=%s",
		encodedURLPrefix, expiration.Unix(), keyName)

	mac := hmac.New(sha1.New, key)
	mac.Write([]byte(input))
	sig := base64.URLEncoding.EncodeToString(mac.Sum(nil))

	signedValue := fmt.Sprintf("%s:Signature=%s",
		input,
		sig,
	)

	return signedValue, nil
}

Java

Visualizza su GitHub Feedback

import java.net.MalformedURLException;
import java.net.URL;
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Paths;
import java.security.InvalidKeyException;
import java.security.Key;
import java.security.NoSuchAlgorithmException;
import java.time.ZonedDateTime;
import java.util.Base64;
import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;

public class SignedCookies {

  public static void main(String[] args) throws Exception {
    // TODO(developer): Replace these variables before running the sample.

    // The name of the signing key must match a key added to the back end bucket or service.
    String keyName = "YOUR-KEY-NAME";
    // Path to the URL signing key uploaded to the backend service/bucket.
    String keyPath = "/path/to/key";
    // The Unix timestamp that the signed URL expires.
    long expirationTime = ZonedDateTime.now().plusDays(1).toEpochSecond();
    // URL prefix to sign as a string. URL prefix must start with either "http://" or "https://"
    // and must not include query parameters.
    String urlPrefix = "https://media.example.com/videos/";

    // Read the key as a base64 url-safe encoded string, then convert to byte array.
    // Key used in signing must be in raw form (not base64url-encoded).
    String base64String = new String(Files.readAllBytes(Paths.get(keyPath)),
        StandardCharsets.UTF_8);
    byte[] keyBytes = Base64.getUrlDecoder().decode(base64String);

    // Create signed cookie from policy.
    String signedCookie = signCookie(urlPrefix, keyBytes, keyName, expirationTime);
    System.out.println(signedCookie);
  }

  // Creates a signed cookie for the specified policy.
  public static String signCookie(String urlPrefix, byte[] key, String keyName,
      long expirationTime)
      throws InvalidKeyException, NoSuchAlgorithmException {

    // Validate input URL prefix.
    try {
      URL validatedUrlPrefix = new URL(urlPrefix);
      if (!validatedUrlPrefix.getProtocol().startsWith("http")) {
        throw new IllegalArgumentException(
            "urlPrefix must start with either http:// or https://: " + urlPrefix);
      }
      if (validatedUrlPrefix.getQuery() != null) {
        throw new IllegalArgumentException("urlPrefix must not include query params: " + urlPrefix);
      }
    } catch (MalformedURLException e) {
      throw new IllegalArgumentException(
          "urlPrefix malformed: " + urlPrefix);
    }

    String encodedUrlPrefix = Base64.getUrlEncoder().encodeToString(urlPrefix.getBytes(
        StandardCharsets.UTF_8));
    String policyToSign = String.format("URLPrefix=%s:Expires=%d:KeyName=%s", encodedUrlPrefix,
        expirationTime, keyName);

    String signature = getSignatureForUrl(key, policyToSign);
    return String.format("Cloud-CDN-Cookie=%s:Signature=%s", policyToSign, signature);
  }

  // Creates signature for input string with private key.
  private static String getSignatureForUrl(byte[] privateKey, String input)
      throws InvalidKeyException, NoSuchAlgorithmException {

    final String algorithm = "HmacSHA256";
    final int offset = 0;
    Key key = new SecretKeySpec(privateKey, offset, privateKey.length, algorithm);
    Mac mac = Mac.getInstance(algorithm);
    mac.init(key);
    return Base64.getUrlEncoder()
        .encodeToString(mac.doFinal(input.getBytes(StandardCharsets.UTF_8)));
  }
}

Python

Visualizza su GitHub Feedback

def sign_cookie(
    url_prefix: str,
    key_name: str,
    base64_key: str,
    expiration_time: datetime,
) -> str:
    """Gets the Signed cookie value for the specified URL prefix and configuration.

    Args:
        url_prefix: URL prefix to sign.
        key_name: name of the signing key.
        base64_key: signing key as a base64 encoded string.
        expiration_time: expiration time.

    Returns:
        Returns the Cloud-CDN-Cookie value based on the specified configuration.
    """
    encoded_url_prefix = base64.urlsafe_b64encode(
        url_prefix.strip().encode("utf-8")
    ).decode("utf-8")
    epoch = datetime.utcfromtimestamp(0)
    expiration_timestamp = int((expiration_time - epoch).total_seconds())
    decoded_key = base64.urlsafe_b64decode(base64_key)

    policy = f"URLPrefix={encoded_url_prefix}:Expires={expiration_timestamp}:KeyName={key_name}"

    digest = hmac.new(decoded_key, policy.encode("utf-8"), hashlib.sha1).digest()
    signature = base64.urlsafe_b64encode(digest).decode("utf-8")

    signed_policy = f"Cloud-CDN-Cookie={policy}:Signature={signature}"

    return signed_policy

Convalidare i cookie firmati

Il processo di convalida di un cookie firmato è essenzialmente lo stesso della generazione di un cookie firmato. Ad esempio, supponiamo che tu voglia convalidare la seguente intestazione di cookie firmata:

Cookie: Cloud-CDN-Cookie=URLPrefix=URL_PREFIX:Expires=EXPIRATION:KeyName=KEY_NAME:Signature=SIGNATURE; Domain=media.example.com; Path=/; Expires=Tue, 20 Aug 2019 02:26:49 GMT; HttpOnly

Puoi utilizzare la chiave segreta denominata da KEY_NAME per generare in modo indipendente la firma e quindi verificare che corrisponda a SIGNATURE.

Produzione di cookie per gli utenti

La tua applicazione deve generare ed emettere a ogni utente (client) un unico cookie HTTP contenente un criterio firmato correttamente:

1. Crea un firmatario HMAC-SHA-1 nel codice dell'applicazione.

2. Firma il criterio utilizzando la chiave scelta, prendendo nota del nome della chiave che hai aggiunto al backend, ad esempio mySigningKey.

3. Crea un criterio dei cookie con il formato seguente, tenendo presente che sia il nome sia il valore fanno distinzione tra maiuscole e minuscole:

   Name: Cloud-CDN-Cookie
   Value: URLPrefix=$BASE64URLECNODEDURLORPREFIX:Expires=$TIMESTAMP:KeyName=$KEYNAME:Signature=$BASE64URLENCODEDHMAC
   

   Esempio di intestazione Set-Cookie:

   Set-Cookie: Cloud-CDN-Cookie=URLPrefix=aHR0cHM6Ly9tZWRpYS5leGFtcGxlLmNvbS92aWRlb3Mv:Expires=1566268009:KeyName=mySigningKey:Signature=0W2xlMlQykL2TG59UZnnHzkxoaw=; Domain=media.example.com; Path=/; Expires=Tue, 20 Aug 2019 02:26:49 GMT; HttpOnly
   

   Gli attributi Domain e Path nel cookie determinano se il client invia il cookie a Cloud CDN.

Consigli e requisiti

• Imposta in modo esplicito gli attributi Domain e Path in modo che corrispondano al dominio e al prefisso del percorso da cui intendi pubblicare i contenuti protetti, che potrebbe differire dal dominio e dal percorso in cui viene emesso il cookie (example.com rispetto a media.example.com o /browse rispetto a /videos).

• Assicurati di avere un solo cookie con un determinato nome per gli stessi Domain e Path.

• Assicurati di non emettere cookie in conflitto perché ciò potrebbe impedire l'accesso ai contenuti in altre sessioni del browser (finestre o schede).

• Imposta i flag Secure e HttpOnly, ove applicabile. Secure assicura che il cookie venga inviato solo tramite connessioni HTTPS. HttpOnly impedisce di rendere il cookie disponibile a JavaScript.

• Gli attributi cookie Expires e Max-Age sono facoltativi. Se le ometti, esiste il cookie mentre esiste la sessione del browser (scheda, finestra).

  Nota: l'attributo Expires qui menzionato è quello che (se presente) viene visualizzato al di fuori del valore del cookie. Non confondere questo attributo con il parametro Expires contenuto nel valore del cookie, che è obbligatorio. Il parametro Expires contenuto nel valore del cookie indica il limite di tempo entro il quale Cloud CDN consente all'utente di accedere al contenuto protetto. Questo limite di tempo è indipendente dalla durata dei cookie.

• In caso di riempimento o fallimento della cache, il cookie firmato viene passato all'origine definita nel servizio di backend. Assicurati di convalidare il valore del cookie firmato su ogni richiesta prima di pubblicare i contenuti.