Questa pagina fornisce una panoramica degli URL firmati e le istruzioni per utilizzarli con Cloud CDN. Gli URL firmati offrono a chiunque l'accesso alle risorse per un periodo limitato nel tempo dell'URL, indipendentemente dal fatto che l'utente disponga o meno di un Account Google.
Un URL firmato è un URL che fornisce autorizzazioni e 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 l'autorizzazione sufficiente per effettuare la richiesta associata all'URL.
Dopo aver generato un URL firmato, chiunque lo possiede può utilizzare URL per eseguire azioni specifiche (ad esempio la lettura di un oggetto) all'interno di un specificato per il periodo di tempo.
Gli URL firmati supportano anche un parametro facoltativo URLPrefix
, che consente di:
forniscono l'accesso a più URL in base a un prefisso comune.
Se vuoi limitare l'accesso a un prefisso URL specifico, considera utilizzando 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 di URL firmati su un backend prima di abilitare Cloud CDN, ma non avrà alcun effetto finché non sarà abilitato Cloud CDN.
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 o i cookie firmati richiede diversi passaggi, descritti nelle sezioni seguenti.
Considerazioni sulla sicurezza
Cloud CDN non convalida le richieste nelle seguenti circostanze:
- La richiesta non è firmata.
- Il servizio di backend o il bucket di backend per la richiesta non contiene Cloud CDN abilitato.
Le richieste firmate devono sempre essere convalidate all'origine prima di inviare la risposta. Questo perché le origini possono essere utilizzate per pubblicare una combinazione di e non firmati e perché un client potrebbe accedere direttamente all'origine.
- Cloud CDN non blocca le richieste senza una query
Signature
o il cookie HTTPCloud-CDN-Cookie
. Rifiuta le richieste con parametri non validi (o con formato non valido). - Quando la tua applicazione rileva una firma non valida, assicurati che il tuo
l'applicazione risponde con un codice di risposta
HTTP 403 (Unauthorized)
. I codici di risposta diHTTP 403
non sono memorizzabili nella cache. - Le risposte alle richieste firmate e non firmate vengono memorizzate nella cache separatamente, quindi una risposta corretta a una richiesta firmata valida non viene mai utilizzata per richiesta non firmata.
- Se la tua applicazione invia un codice di risposta memorizzabile in cache a una richiesta non valida, le richieste future valide potrebbero essere rifiutate erroneamente.
Per i backend Cloud Storage, assicurati di rimuovi l'accesso pubblico, in modo che Cloud Storage possa rifiutare le richieste prive di un indirizzo firma.
La seguente tabella riassume il comportamento.
La richiesta ha la firma | Hit della cache | Comportamento |
---|---|---|
No | No | Inoltra all'origine del backend. |
No | Sì | Pubblica dalla cache. |
Sì | No | Convalida la firma. Se valido, esegui l'inoltro all'origine del backend. |
Sì | Sì | Convalida la firma. Se valido, pubblica dalla cache. |
Creare chiavi per richieste firmate
Per attivare il supporto degli URL e dei cookie firmati di Cloud CDN, crea una o più chiavi su 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 dettate dalle tue esigenze di sicurezza. Per ogni backend possono essere configurate fino a tre chiavi alla volta. Ti suggeriamo di ruotare periodicamente le chiavi eliminando le chiavi più vecchie aggiungendo una nuova chiave e utilizzando la nuova chiave quando si firmano URL o cookie.
Puoi utilizzare lo stesso nome di chiave in più servizi e bucket di backend poiché ogni set di chiavi è indipendente l'uno dall'altro. I nomi delle chiavi possono essere 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 ne abbia uno le chiavi possono creare URL e cookie firmati che Cloud CDN accetta finché la chiave non viene eliminata da Cloud CDN. Le chiavi sono memorizzate su il computer in cui vengono generati gli URL 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 a nessun 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 lo Sezione Regole host e percorso.
- Nella sezione Regole host e percorso, fai clic su Avanti per aprire lo Sezione Prestazioni della cache.
- Nella sezione Contenuti con limitazioni, seleziona Limita l'accesso tramite 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 accedere, quindi specifica una chiave di firma. valore.
Per la prima opzione, copia il valore della chiave 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 di 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 specificato. Il file della chiave deve essere creato generando un codice 128 casuale forte
bit, codificandoli con base64 e sostituendo il carattere +
con
-
e sostituendo il carattere /
con _
. Per ulteriori informazioni, vedi
RFC 4648.
È fondamentale che la chiave sia fortemente casuale. In un sistema simile a UNIX, puoi
genera una chiave fortemente casuale e la archivia nel file della chiave con
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 chi può leggere gli oggetti, devi concedere a Cloud CDN l'autorizzazione a leggere gli oggetti aggiungendo l'account di servizio Cloud CDN ai criteri 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 ne aggiungi uno o più chiavi per il progetto.
gcloud storage buckets add-iam-policy-binding gs://BUCKET \ --member=serviceAccount:service-PROJECT_NUM@cloud-cdn-fill.iam.gserviceaccount.com \ --role=roles/storage.objectViewer
Sostituisci PROJECT_NUM
con il numero del tuo progetto e
BUCKET
con il tuo bucket di archiviazione.
L'account di servizio Cloud CDN
service-PROJECT_NUM@cloud-cdn-fill.iam.gserviceaccount.com
non è presente nell'elenco degli account di servizio del tuo progetto. Questo perché
l'account di servizio Cloud CDN è di proprietà di Cloud CDN, non del tuo
progetto.
Per saperne di più sui numeri di progetto, consulta la sezione Trovare l'ID progetto e il numero di progetto nella documentazione della guida della console Google Cloud.
Personalizza il tempo massimo di memorizzazione nella cache
Cloud CDN memorizza nella cache le risposte per le richieste firmate indipendentemente dal
all'intestazione Cache-Control
del backend. Il tempo massimo per cui le risposte possono essere memorizzate nella cache
senza riconvalida viene impostato dal flag signed-url-cache-max-age
, che
il valore predefinito è un'ora e possono essere modificati come mostrato qui.
Per impostare il tempo massimo 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 firmata
Per elencare le chiavi in un servizio di backend o in un bucket di backend, esegui una delle 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 una delle 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
Firma degli URL
L'ultimo passaggio consiste nel firmare gli URL e distribuirli. Puoi firmare gli URL utilizzando
il comando gcloud compute sign-url
oppure utilizzando il codice che scrivi 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
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 utilizza Google Cloud CLI o scrivi codice personalizzato mediante i seguenti esempi.
gcloud
Google Cloud CLI include un comando per la firma degli URL. La implementa l'algoritmo descritto nella sezione scrivendo il tuo 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 base64url codificato.
chiave-valore da KEY_FILE_NAME
, quindi restituisce un
URL firmato che puoi utilizzare per 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 percorso
di strumento di authoring. Ad esempio, http://example.com
non è valido, ma
https://example.com/
e https://example.com/whatever
sono entrambi validi
URL.
Se viene fornito il flag facoltativo --validate
, questo comando invia un messaggio HEAD
con l'URL risultante e stampa il codice di risposta HTTP. Se l'URL firmato è corretto, il codice di risposta corrisponde a quello del codice risultato inviato dal tuo backend. Se il codice di risposta non è lo stesso, ricontrolla
KEY_NAME
e i contenuti del file specificato
e assicurati che il valore di
KEY_NAME
sia di almeno alcuni 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.
Vai
Ruby
.NET
Java
Python
PHP
Creare programmaticamente URL firmati con un prefisso URL
I seguenti esempi di codice mostrano come creare in modo programmatico URL con un prefisso URL.
Vai
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 che segue; tutti i parametri URL sono sensibile alle maiuscole e deve 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 richiesta nel fuso orario UTC (il numero di secondi a partire da 1970-01-01 00:00:00 UTC). Per massimizzare la sicurezza, imposta il valore sul periodo di tempo più breve possibile per il tuo caso d'uso. La più a lungo un URL firmato è valido, maggiore è il rischio che l'utente per condividerlo con altri, accidentalmente o meno.Imposta il nome della chiave. L'URL deve essere firmato con una chiave del servizio di backend o bucket di backend che gestisce l'URL. È preferibile utilizzare la chiave aggiunta più di recente per la rotazione della chiave. Aggiungi la chiave all'URL nel seguente modo: aggiungendo
&KeyName=KEY_NAME
. SostituisciKEY_NAME
con nome della chiave scelta creata in Creazione di chiavi di richiesta firmate.Firma l'URL. Crea l'URL firmato seguendo questa procedura. Accertati che i parametri di ricerca siano nell'ordine mostrato immediatamente prima del passaggio 1 e assicurati che le maiuscole/minuscole nell'URL firmato non cambino.
a. Esegui l'hashing dell'intero URL (incluso
http://
ohttps://
all'inizio) e&KeyName...
alla fine) con HMAC-SHA1 utilizzando il secret corrispondente al nome della chiave scelto in precedenza. Usa la versione non elaborata da 16 byte chiave privata, non la chiave codificata base64url. Decodificalo se necessario.b. Utilizza la codifica base64url. per codificare il risultato.
c. Aggiungi
&Signature=
all'URL, seguito dalla firma codificata.
Utilizzare i prefissi URL per gli URL firmati
Invece di firmare l'URL completo della richiesta con la query Expires
e KeyName
puoi firmare la query URLPrefix
, Expires
e KeyName
. Ciò consente una determinata combinazione di URLPrefix
, Expires
,
Parametri di ricerca KeyName
e Signature
da riutilizzare testualmente
più URL che corrispondono a URLPrefix
, evitando di dover creare un nuovo
per ogni URL.
Nell'esempio seguente, il testo evidenziato mostra i parametri che firmi. Signature
viene aggiunto come query finale
come al solito.
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, se accedi con URLPrefix
firmando i parametri di ricerca, in modo che possano essere inclusi liberamente
URL. Inoltre, a differenza delle firme degli URL di richiesta completi,
possono apparire sia prima che dopo i parametri di ricerca che compongono
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 e sicuro per l'URL che include tutte
percorsi per i quali deve essere valida la firma.
Un URLPrefix
codifica uno schema (http://
o https://
), un FQDN e un
percorso facoltativo. La fine del percorso con /
è facoltativa, ma consigliata. La
non deve includere parametri di ricerca o frammenti come ?
o #
.
Ad esempio, https://media.example.com/videos
associa le richieste a entrambi
seguenti:
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 i
seguenti:
/data/file1
/database
Per evitare questo errore, ti consigliamo di terminare tutti i prefissi con /
, a meno che 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 è essenzialmente la stessa della generazione di un l'URL firmato. Ad esempio, supponiamo che tu voglia convalidare le seguenti URL:
https://example.com/PATH?Expires=EXPIRATION&KeyName=KEY_NAME&Signature=SIGNATURE
Puoi usare la chiave segreta denominata da KEY_NAME
per
per generare la firma in modo indipendente 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
è 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
.
Per i metodi di firma basati su URL, in cui la firma fa parte della query
parametri o incorporati come componente del percorso dell'URL, la firma e i relativi
vengono rimossi dall'URL prima che la richiesta venga inviata
origine dati. In questo modo si evita che la firma causi problemi di routing quando
che gestisce la richiesta. Per convalidare queste richieste, puoi ispezionare l'intestazione della richiesta x-client-request-url
, che include l'URL della richiesta del client originale (firmato) prima della rimozione dei componenti firmati.
Rimuovi l'accesso pubblico al bucket Cloud Storage
Affinché gli URL firmati proteggono correttamente i contenuti, è importante che il parametro
server di origine non concede accesso pubblico a quei contenuti. Se utilizzi un
nel bucket Cloud Storage, un approccio comune consiste nel rendere gli oggetti pubblici
temporaneamente a scopo di test. Dopo aver attivato gli URL firmati, è importante rimuovere le autorizzazioni di LETTURA allUsers
(e allAuthenticatedUsers
, se applicabili) (in altre parole, il ruolo IAM Storage Object Viewer) nel bucket.
Dopo aver disattivato l'accesso pubblico al bucket, i singoli utenti possono comunque accedere a Cloud Storage senza URL firmati se dispongono dell'autorizzazione di accesso, come l'autorizzazione PROPRIETARIO.
Per rimuovere l'accesso pubblico in lettura allUsers
in un bucket Cloud Storage,
annullare l'azione descritta in
Rendere pubblicamente leggibili tutti gli oggetti in un bucket.
Distribuire e utilizzare gli URL firmati
L'URL restituito da Google Cloud CLI o generato dal prompt
il codice può essere distribuito in base alle tue esigenze. Ti consigliamo di firmare solo su HTTPS
URL, perché HTTPS fornisce un trasporto sicuro che impedisce a Signature
dell'URL firmato. Analogamente, assicurati di distribuire gli URL firmati tramite protocolli di trasporto sicuri come TLS/HTTPS.