Questa pagina fornisce una panoramica degli URL firmati e le istruzioni per utilizzarli con Cloud CDN. Gli URL firmati offrono a chiunque sia in possesso dell'URL l'accesso alle risorse per un periodo limitato, indipendentemente dal fatto che l'utente disponga o meno di un Account Google.
Un URL firmato è un URL che fornisce un'autorizzazione e un tempo limitati per effettuare una richiesta. Gli URL firmati contengono informazioni di autenticazione nelle stringhe di query, consentendo agli utenti senza credenziali di eseguire azioni specifiche su una risorsa. Quando generi un URL firmato, specifichi un account utente o di servizio che deve avere autorizzazioni sufficienti per effettuare la richiesta associata all'URL.
Dopo aver generato un URL firmato, chiunque lo possiede può utilizzarlo per eseguire azioni specifiche (come la lettura di un oggetto) entro un periodo di tempo specificato.
Gli URL firmati supportano anche un parametro facoltativo URLPrefix
, che consente di
fornire l'accesso a più URL in base a un prefisso comune.
Se vuoi limitare l'accesso a un prefisso URL specifico, ti consigliamo di utilizzare i cookie firmati.
Prima di iniziare
Prima di utilizzare gli URL firmati, segui questi passaggi:
Assicurati che Cloud CDN sia abilitato. Per le istruzioni, vedi Utilizzo di Cloud CDN. Puoi configurare URL firmati su un backend prima di abilitare Cloud CDN, ma non vi è alcun effetto finché Cloud CDN non viene abilitato.
Se necessario, esegui l'aggiornamento alla versione più recente di Google Cloud CLI:
gcloud components update
Per una panoramica, consulta la sezione URL e cookie firmati.
Configura le chiavi di richiesta firmate
La creazione di chiavi per gli URL e i cookie firmati richiede diversi passaggi, descritti nelle sezioni che seguono.
Considerazioni sulla sicurezza
Cloud CDN non convalida le richieste nelle seguenti circostanze:
- La richiesta non è firmata.
- Cloud CDN non è abilitato per il servizio di backend o il bucket di backend per la richiesta.
Le richieste firmate devono sempre essere convalidate all'origine prima di fornire la risposta. Questo 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 query
Signature
o un cookie HTTPCloud-CDN-Cookie
. Le richieste con parametri di richiesta non validi (o con un formato diverso) vengono rifiutate. - Quando l'applicazione rileva una firma non valida, assicurati che l'applicazione risponda con un codice di risposta
HTTP 403 (Unauthorized)
. I codici di risposta diHTTP 403
non sono memorizzabili nella cache. - Le risposte a richieste firmate e non firmate vengono memorizzate separatamente nella cache, quindi una risposta riuscita a una richiesta firmata valida non viene mai utilizzata per gestire una richiesta non firmata.
- Se l'applicazione invia un codice di risposta memorizzabile nella cache a una richiesta non valida, le richieste future valide potrebbero essere rifiutate erroneamente.
Per i backend Cloud Storage, assicurati di rimuovere l'accesso pubblico, in modo che Cloud Storage possa rifiutare le richieste prive di una firma valida.
La seguente tabella riassume il comportamento.
La richiesta ha la firma | Successo della cache | Comportamento |
---|---|---|
No | No | Inoltra all'origine del backend. |
No | Sì | Pubblica dalla cache. |
Sì | No | Convalida firma. Se valido, esegui l'inoltro all'origine del backend. |
Sì | Sì | Convalida firma. Se valido, pubblica dalla cache. |
Crea chiavi di richiesta firmate
Puoi abilitare il supporto degli URL e dei cookie firmati di Cloud CDN creando una o più chiavi in un servizio di backend, un bucket di backend o entrambi abilitati per Cloud CDN.
Per ogni servizio di backend o bucket di backend, puoi creare ed eliminare chiavi in base alle tue esigenze di sicurezza. Per ogni backend possono essere configurate fino a tre chiavi alla volta. Ti consigliamo di ruotare periodicamente le chiavi eliminando quella meno recente, aggiungendo una nuova chiave e utilizzando la nuova chiave quando firmi URL o cookie.
Puoi usare lo stesso nome di chiave in più servizi e bucket di backend poiché ogni set di chiavi è indipendente gli 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 chiavi, assicurati di tenerle al sicuro, perché chiunque ne abbia una può creare URL e 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, le coppie chiave-valore non vengono incluse nelle risposte alle richieste API. Se perdi una chiave, devi crearne una nuova.
Per creare una chiave di richiesta firmata, segui questi passaggi.
Console
- Nella console Google Cloud, vai alla pagina Cloud CDN.
- Fai clic sul nome dell'origine a cui vuoi aggiungere la chiave.
- Nella pagina Dettagli origine, fai clic sul pulsante Modifica.
- Nella sezione Nozioni di base sull'origine, fai clic su Avanti per aprire la sezione Regole host e percorso.
- Nella sezione Regole host e percorso, fai clic su Avanti per aprire la sezione Prestazioni della cache.
- Nella sezione Contenuti con limitazioni, seleziona Limita l'accesso utilizzando URL e cookie firmati.
Fai clic su Aggiungi chiave di firma.
- Specifica un nome univoco per la nuova chiave di firma.
Nella sezione Metodo di creazione della chiave, seleziona Genera automaticamente. In alternativa, fai clic su Fammi inserire e specifica una coppia chiave di firma.
Per la prima opzione, copia la coppia chiave-valore di firma generata automaticamente in un file privato, che puoi utilizzare per creare URL firmati.
Fai clic su Fine.
Nella sezione Durata massima delle voci della cache, inserisci un valore, quindi seleziona un'unità di tempo.
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 con frequenza elevata e codificandoli in base64, quindi sostituendo il carattere +
con -
e il carattere /
con _
. Per ulteriori informazioni, consulta RFC 4648.
È fondamentale che la chiave sia fortemente casuale. In un sistema simile a UNIX, puoi generare una chiave altamente 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
Configura le autorizzazioni per Cloud Storage
Se utilizzi Cloud Storage e hai limitato la lettura degli 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 questo comando, aggiungi almeno una chiave a un bucket di backend nel tuo progetto. In caso contrario, il comando non va a buon fine e restituisce un errore perché l'account di servizio di riempimento della cache di Cloud CDN non viene creato finché non aggiungi una o più chiavi per il progetto. Sostituisci PROJECT_NUM
con il numero del tuo progetto e BUCKET
con il bucket di archiviazione.
gsutil iam ch \ serviceAccount:service-PROJECT_NUM@cloud-cdn-fill.iam.gserviceaccount.com:objectViewer \ gs://BUCKET
L'account di servizio Cloud CDN
service-PROJECT_NUM@cloud-cdn-fill.iam.gserviceaccount.com
non viene visualizzato nell'elenco degli account di servizio del progetto. Il motivo è che l'account di servizio Cloud CDN è di proprietà di Cloud CDN, non del tuo progetto.
Per ulteriori informazioni sui numeri di progetto, consulta Individuare l'ID e il numero del progetto nella documentazione di assistenza della console Google Cloud.
Personalizza il tempo massimo di memorizzazione nella cache
Cloud CDN memorizza nella cache le risposte per le richieste firmate a prescindere dall'intestazione Cache-Control
del backend. Il tempo massimo per cui le risposte possono essere memorizzate nella cache
senza riconvalida è impostato dal flag signed-url-cache-max-age
, che
il valore predefinito è un'ora e può essere modificato come mostrato qui.
Per impostare il tempo massimo della cache per un servizio di backend 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 firmata
Per elencare le chiavi in un servizio di backend o un bucket di backend, esegui uno dei seguenti comandi:
gcloud compute backend-services describe BACKEND_NAME
gcloud compute backend-buckets describe BACKEND_NAME
Elimina le chiavi di richiesta firmate
Quando gli URL firmati da una determinata chiave non devono più essere rispettati, esegui uno dei seguenti comandi per eliminare questa 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
Firma degli URL
L'ultimo passaggio consiste nel firmare gli URL e distribuirli. Puoi firmare gli URL utilizzando il comando gcloud compute sign-url
o il codice che hai scritto personalmente.
Se hai bisogno di molti URL firmati, il codice personalizzato offre prestazioni migliori.
Crea URL firmati
Segui queste istruzioni per creare URL firmati utilizzando il comando gcloud compute sign-url
. Questo passaggio presuppone che tu abbia già
creato le chiavi.
Console
Non puoi creare URL firmati utilizzando la console Google Cloud. Puoi utilizzare Google Cloud CLI o scrivere codice personalizzato utilizzando gli esempi riportati di seguito.
gcloud
Google Cloud CLI include un comando per la firma degli URL, che implementa l'algoritmo descritto nella sezione dedicata alla scrittura del codice.
gcloud compute sign-url \ "URL" \ --key-name KEY_NAME \ --key-file KEY_FILE_NAME \ --expires-in TIME_UNTIL_EXPIRATION \ [--validate]
Questo comando legge e decodifica il valore chiave base64url codificato
da KEY_FILE_NAME
, quindi restituisce un
URL firmato che puoi utilizzare per le richieste GET
o HEAD
dell'URL specificato.
Ad esempio:
gcloud compute sign-url \ "https://example.com/media/video.mp4" \ --key-name my-test-key \ --expires-in 30m \ --key-file sign-url-key-file
URL
deve essere un URL valido con un componente del percorso. Ad esempio, http://example.com
non è valido, ma https://example.com/
e https://example.com/whatever
sono entrambi URL validi.
Se viene fornito il flag facoltativo --validate
, il comando invia una richiesta HEAD
con l'URL risultante e stampa il codice di risposta HTTP. Se l'URL firmato è corretto, il codice di risposta corrisponde al codice risultato inviato dal backend. Se il codice di risposta non è lo stesso, ricontrolla KEY_NAME
e i contenuti del file specificato e assicurati che il valore di TIME_UNTIL_EXPIRATION
sia di almeno diversi secondi.
Se il flag --validate
non viene fornito, non vengono verificati i seguenti elementi:
- Gli input
- L'URL generato
- L'URL firmato generato
Creare URL firmati in modo programmatico
I seguenti esempi di codice mostrano come creare in modo programmatico URL firmati.
Go
Ruby
.NET
Java
Python
PHP
Creare in modo programmatico URL firmati con un prefisso URL
I seguenti esempi di codice mostrano come creare in modo programmatico URL firmati con un prefisso URL.
Go
Java
Python
Generare URL firmati personalizzati
Quando scrivi il tuo codice per generare URL firmati, il tuo obiettivo è creare URL con il formato o l'algoritmo seguente; tutti i parametri URL sono sensibili alle maiuscole e devono essere nell'ordine mostrato:
https://example.com/foo?Expires=EXPIRATION&KeyName=KEY_NAME&Signature=SIGNATURE
Per generare URL firmati, segui questi passaggi:
Assicurati che l'URL per la firma non abbia un parametro di query
Signature
.Determina quando scade l'URL e aggiungi un parametro di query
Expires
con la scadenza desiderata nel fuso orario UTC (il numero di secondi a partire dal 1° gennaio 1970 00:00:00 UTC). Per massimizzare la sicurezza, imposta il valore sul periodo di tempo più breve possibile per il tuo caso d'uso. Più lungo un URL firmato è valido, maggiore è il rischio che l'utente che lo fornisci lo condivida con altri, per errore o in altro modo.Imposta il nome della chiave. L'URL deve essere firmato con una chiave del servizio di backend o del bucket di backend che pubblica l'URL. È meglio usare la chiave aggiunta più di recente per rotazione della chiave. Aggiungi la chiave all'URL aggiungendo
&KeyName=KEY_NAME
. SostituisciKEY_NAME
con il nome della chiave scelta creata nella sezione Creazione di chiavi di richiesta firmate.Firma l'URL. Crea l'URL firmato seguendo questa procedura. Assicurati che i parametri di ricerca siano nell'ordine mostrato immediatamente prima del passaggio 1 e assicurati che non ci sia nulla nell'URL firmato per cambiare le maiuscole e le minuscole.
a. Esegui l'hashing dell'intero URL (inclusi
http://
ohttps://
all'inizio e&KeyName...
alla fine) con HMAC-SHA1 utilizzando la chiave secret che corrisponde al nome della chiave scelto in precedenza. Utilizza la chiave secret non elaborata da 16 byte, non la chiave codificata base64url. Decodificalo, se necessario.b. Usa la codifica base64url per codificare il risultato.
c. Aggiungi
&Signature=
all'URL, seguito dalla firma codificata.
Utilizzare i prefissi URL per gli URL firmati
Anziché firmare l'URL completo della richiesta con i parametri di query Expires
e KeyName
, puoi firmare solo i parametri di query URLPrefix
, Expires
e KeyName
. In questo modo, una determinata combinazione di parametri di ricerca URLPrefix
, Expires
, KeyName
e Signature
può essere riutilizzata testualmente in
più URL corrispondenti a URLPrefix
, evitando di creare una nuova
firma per ogni URL distinto.
Nell'esempio seguente, il testo evidenziato mostra
i parametri che firmi. Signature
viene aggiunto come parametro
di query finale, come di consueto.
https://media.example.com/videos/id/master.m3u8?userID=abc123&starting_profile=1&URLPrefix=aHR0cHM6Ly9tZWRpYS5leGFtcGxlLmNvbS92aWRlb3Mv&Expires=1566268009&KeyName=mySigningKey&Signature=8NBSdQGzvDftrOIa3WHpp646Iis=
A differenza della firma di un URL di richiesta completo, quando si firma con URLPrefix
non si firma alcun parametri di ricerca, quindi parametri di ricerca possono essere inclusi liberamente nell'URL. Inoltre, a differenza delle firme degli URL di richiesta completi, questi parametri di ricerca aggiuntivi possono apparire sia prima che dopo i parametri di ricerca che compongono la firma. Di conseguenza, anche il seguente è un URL valido con un prefisso URL firmato:
https://media.example.com/videos/id/master.m3u8?userID=abc123&URLPrefix=aHR0cHM6Ly9tZWRpYS5leGFtcGxlLmNvbS92aWRlb3Mv&Expires=1566268009&KeyName=mySigningKey&Signature=8NBSdQGzvDftrOIa3WHpp646Iis=&starting_profile=1
URLPrefix
indica un prefisso URL con codifica Base64 sicuro per l'URL che comprende tutti i percorsi per i quali deve essere valida la firma.
Un URLPrefix
codifica uno schema (http://
o https://
), un nome di dominio completo e un
percorso facoltativo. La fine del percorso con /
è facoltativa, ma consigliata. Il
prefisso non deve includereparametri di ricercay o frammenti come ?
o #
.
Ad esempio, https://media.example.com/videos
associa le richieste a entrambi i seguenti elementi:
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 strettamente un percorso di directory.
Ad esempio, il prefisso https://example.com/data
concede l'accesso a entrambi:
/data/file1
/database
Per evitare l'errore, ti consigliamo di terminare tutti i prefissi con /
, a meno che tu non scelga intenzionalmente di terminare il prefisso con un nome file parziale come https://media.example.com/videos/123
per concedere l'accesso a quanto segue:
/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.
Convalida gli URL firmati
Il processo di convalida di un URL firmato è sostanzialmente uguale alla generazione di un URL firmato. Ad esempio, supponi di voler convalidare il seguente URL firmato:
https://example.com/PATH?Expires=EXPIRATION&KeyName=KEY_NAME&Signature=SIGNATURE
Puoi utilizzare la chiave segreta denominata da KEY_NAME
per generare in modo indipendente la firma per il seguente URL:
https://example.com/PATH?Expires=EXPIRATION&KeyName=KEY_NAME
Dopodiché potrai verificare che corrisponda a SIGNATURE
.
Supponiamo di voler convalidare un URL firmato che abbia un URLPrefix
, come mostrato qui:
https://example.com/PATH?URLPrefix=URL_PREFIX&Expires=EXPIRATION&KeyName=KEY_NAME&Signature=SIGNATURE
Innanzitutto, verifica che il valore decodificato in base64 di URL_PREFIX
sia un prefisso di https://example.com/PATH
. In tal caso, puoi quindi calcolare la firma per quanto segue:
URLPrefix=URL_PREFIX&Expires=EXPIRATION&KeyName=KEY_NAME
Puoi quindi verificare che corrisponda a SIGNATURE
.
Rimuovi l'accesso pubblico al bucket Cloud Storage
Affinché gli URL firmati proteggono correttamente i contenuti, è importante che il server di origine non conceda l'accesso pubblico a questi contenuti. Quando utilizzi un bucket Cloud Storage, un approccio comune consiste nel rendere gli oggetti pubblici temporaneamente a scopo di test. Dopo aver abilitato gli URL firmati, è importante rimuovere le autorizzazioni READ di allUsers
(e allAuthenticatedUsers
, se applicabile) (in altre parole, il ruolo IAM Visualizzatore oggetti Storage) sul bucket.
Dopo aver disabilitato l'accesso pubblico nel bucket, i singoli utenti possono comunque accedere a Cloud Storage senza URL firmati se dispongono dell'autorizzazione di accesso, ad esempio l'autorizzazione di PROPRIETARIO.
Per rimuovere l'accesso pubblico in lettura allUsers
da un bucket Cloud Storage,
inverti l'azione descritta in
Rendere pubblicamente leggibili tutti gli oggetti di un bucket.
Distribuzione e utilizzo di URL firmati
L'URL restituito da Google Cloud CLI o generato dal codice personalizzato può essere distribuito in base alle tue esigenze. Ti consigliamo di firmare solo gli URL HTTPS, perché HTTPS fornisce un trasporto sicuro che impedisce l'intercettazione del componente Signature
dell'URL firmato. Allo stesso modo, assicurati di distribuire gli URL firmati tramite protocolli di trasporto sicuri come TLS/HTTPS.