Questa pagina fornisce una panoramica sugli URL firmati e le istruzioni per utilizzarli con Cloud CDN. Gli URL firmati forniscono accesso alle risorse a tempo limitato a chiunque sia in possesso dell'URL, indipendentemente dal fatto che l'utente abbia 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 rispettive stringhe di query, consentendo così agli utenti senza credenziali di eseguire azioni specifiche su una risorsa. Quando generi un URL firmato, specifichi un utente o un service account che deve disporre di autorizzazioni sufficienti per effettuare la richiesta associata all'URL.
Dopo aver generato un URL firmato, chiunque lo possieda può utilizzarlo per eseguire azioni specifiche (ad esempio leggere un oggetto) entro un periodo di tempo specificato.
Gli URL firmati supportano anche un parametro URLPrefix facoltativo, 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, valuta la possibilità di utilizzare i cookie firmati.
Prima di iniziare
Prima di utilizzare gli URL firmati, completa i seguenti passaggi:
Assicurati che Cloud CDN sia abilitato. Per istruzioni, consulta Utilizzo di Cloud CDN. Puoi configurare gli URL firmati su un backend prima di abilitare Cloud CDN, ma la configurazione non ha effetto finché Cloud CDN non è abilitato.
Se necessario, esegui l'aggiornamento all'ultima versione di Google Cloud CLI:
gcloud components update
Per una panoramica, consulta URL e cookie firmati.
Configura le chiavi per le richieste 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 ha Cloud CDN abilitato.
Le richieste firmate devono sempre essere convalidate all'origine prima della pubblicazione della risposta, perché le origini possono essere utilizzate per pubblicare un mix 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
Signatureo un cookie HTTPCloud-CDN-Cookie. Rifiuta le richieste con parametri di richiesta non validi (o con un formato errato). - Quando l'applicazione rileva una firma non valida, assicurati che risponda con un codice di risposta
HTTP 403 (Unauthorized). I codici di rispostaHTTP 403non sono memorizzabili nella cache. - Le risposte alle richieste firmate e non firmate vengono memorizzate separatamente nella cache, pertanto una risposta positiva a una richiesta firmata valida non viene mai utilizzata per pubblicare 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 incorrettamente rifiutate.
Per i backend Cloud Storage, assicurati di rimuovere l'accesso pubblico, in modo che Cloud Storage possa rifiutare le richieste a cui manca una firma valida.
La seguente tabella riassume il comportamento.
| La richiesta ha una firma | Successo della cache | Comportamento |
|---|---|---|
| No | No | Inoltra all'origine di backend. |
| No | Sì | Pubblica dalla cache. |
| Sì | No | Convalida la firma. Se è valida, inoltra all'origine di backend. |
| Sì | Sì | Convalida la firma. Se è valida, pubblica dalla cache. |
Crea le chiavi per le richieste firmate
Per abilitare il supporto per i cookie e gli URL firmati di Cloud CDN, devi creare 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 le chiavi in base alle tue esigenze di sicurezza. Ogni backend può avere fino a tre chiavi configurate alla volta. Ti consigliamo di ruotare periodicamente le chiavi eliminando la più vecchia, aggiungendo una nuova chiave e utilizzandola per firmare URL o cookie.
Puoi utilizzare lo stesso nome della chiave in più servizi di backend 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 proteggerle, perché chiunque ne sia in possesso può creare URL o cookie firmati che Cloud CDN accetta finché la chiave non viene eliminata da Cloud CDN. Le chiavi vengono archiviate sul computer in cui generi gli URL o i cookie firmati. Cloud CDN archivia le chiavi anche per verificare le firme delle richieste.
Per mantenere segrete le chiavi, i valori delle chiavi non sono inclusi nelle risposte a nessuna richiesta 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 Elementi di base dell'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 accesso con 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 chiave, seleziona Genera automaticamente. In alternativa, fai clic su Inserisci e poi specifica un valore per la chiave di firma.
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 e poi seleziona un'unità di tempo.
Fai clic su Fine.
gcloud
Lo strumento a riga di comando gcloud legge le chiavi da un file locale che specifichi. Il file della chiave deve essere creato generando 128 bit fortemente casuali, codificandoli con base64 e sostituendo il carattere + con - e il carattere / con _. Per saperne di più, consulta RFC 4648.
È fondamentale che la chiave sia fortemente casuale. Su un sistema di tipo 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
Configura le autorizzazioni Cloud Storage
Se utilizzi Cloud Storage e hai limitato chi può leggere gli oggetti, devi concedere a Cloud CDN l'autorizzazione per leggere gli oggetti aggiungendo il service account Cloud CDN agli ACL di Cloud Storage.
Non è necessario creare il service account. Il service account 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 tuo progetto. In caso contrario, il comando non va a buon fine e viene visualizzato un errore perché il service account di riempimento della cache di Cloud CDN non viene creato finché non aggiungi una o più chiavi per il progetto.
gcloud storage buckets add-iam-policy-binding gs://BUCKET \ --member=serviceAccount:service-PROJECT_NUMBER@cloud-cdn-fill.iam.gserviceaccount.com \ --role=roles/storage.objectViewer
Sostituisci PROJECT_NUMBER con il numero del progetto e BUCKET con il bucket di archiviazione.
Il service account di Cloud CDN service-PROJECT_NUMBER@cloud-cdn-fill.iam.gserviceaccount.com non viene visualizzato nell'elenco dei service account del tuo progetto. Questo perché il service account di Cloud CDN è di proprietà di Cloud CDN, non del tuo progetto.
Per saperne di più sui numeri di progetto, consulta Individua l'ID progetto e il numero di progetto nella documentazione della guida della console Google Cloud .
Personalizza la durata massima della cache
Cloud CDN memorizza nella cache le risposte per le richieste firmate indipendentemente dall'intestazione Cache-Control del backend. Il tempo massimo per cui le risposte possono essere memorizzate nella cache senza convalida è impostato dal flag signed-url-cache-max-age, che è impostato su un'ora per impostazione predefinita e può essere modificato come mostrato qui.
Per impostare la durata massima 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 per le richieste firmate
Per elencare le chiavi in un servizio di backend o in 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 per le richieste 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
Firma gli URL
L'ultimo passaggio consiste nel firmare gli URL e distribuirli. Puoi firmare gli URL utilizzando il comando gcloud compute sign-url o del codice scritto da te.
Se hai bisogno di molti URL firmati, il codice personalizzato offre prestazioni migliori.
Crea URL firmati
Utilizza 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 firmare gli URL. Il comando implementa l'algoritmo descritto nella sezione sulla 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 della chiave con codifica base64url da KEY_FILE_NAME, quindi restituisce un URL firmato che puoi utilizzare per le richieste GET o HEAD per l'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, questo 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 è uguale al codice di risultato inviato dal backend. Se il codice di risposta non è lo stesso, controlla di nuovo KEY_NAME e i contenuti del file specificato e assicurati che il valore di TIME_UNTIL_EXPIRATION sia di almeno qualche secondo.
Se il flag --validate non viene specificato, gli elementi seguenti non vengono verificati:
- Gli input
- L'URL generato
- L'URL firmato generato
Crea URL firmati in modo programmatico
I seguenti esempi di codice mostrano come creare in modo programmatico URL firmati.
Go
Ruby
.NET
Java
Python
PHP
Crea URL firmati in modo programmatico con un prefisso URL
I seguenti esempi di codice mostrano come creare in modo programmatico URL firmati con un prefisso URL.
Go
Java
Python
Genera URL firmati personalizzati
Quando scrivi il tuo codice per generare URL firmati, il tuo obiettivo è creare URL con il seguente formato o algoritmo; 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 la data di scadenza dell'URL e aggiungi un parametro di query
Expirescon la data di scadenza richiesta in formato UTC (il numero di secondi trascorsi dal 1° gennaio 1970 alle ore 00:00:00 UTC). Per ottimizzare la sicurezza, imposta il valore sul periodo di tempo più breve possibile per il tuo caso d'uso. Più a lungo è valido un URL firmato, maggiore è il rischio che l'utente a cui lo dai lo condivida con altri, in modo accidentale o meno.Imposta il nome della chiave. L'URL deve essere firmato con una chiave del servizio di backend o del bucket di backend che lo pubblica. È consigliabile utilizzare la chiave aggiunta più di recente alla rotazione della chiave. Aggiungi la chiave all'URL aggiungendo
&KeyName=KEY_NAME. SostituisciKEY_NAMEcon il nome della chiave scelta creata in Crea le chiavi per le richieste firmate.Firma l'URL. Crea l'URL firmato seguendo questi passaggi. Assicurati che i parametri di query siano nell'ordine mostrato immediatamente prima del passaggio 1 e che non venga modificata la distinzione tra maiuscole e minuscole nell'URL firmato.
a. Esegui l'hashing dell'intero URL (inclusi
http://ohttps://all'inizio e&KeyName...alla fine) con HMAC-SHA1 utilizzando la chiave segreta corrispondente al nome della chiave scelto in precedenza. Utilizza la chiave segreta non elaborata a 16 byte, non quella con codifica base64url. Decodificala se necessario.b. Utilizza la codifica base64url per codificare il risultato.
c. Aggiungi
&Signature=all'URL, seguito dalla firma codificata. Non convertire i caratteri=finali della firma nella loro forma codificata a percentuale,%3D.
Utilizza i prefissi URL per gli URL firmati
Invece di firmare l'URL della richiesta completo con i parametri di query Expires e KeyName, puoi firmare solo i parametri di query URLPrefix, Expires e KeyName. Ciò consente di riutilizzare letteralmente una determinata combinazione di parametri di query URLPrefix, Expires, KeyName e Signature in più URL che corrispondono a URLPrefix, evitando la necessità 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 firmi con URLPrefix non firmi alcuni parametri di query, quindi i parametri di query possono essere inclusi liberamente nell'URL. A differenza delle firme URL di richiesta complete, questi parametri di query aggiuntivi possono essere visualizzati sia prima che dopo i parametri di query 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 URL che comprende tutti i percorsi per cui la firma deve essere valida.
Un URLPrefix codifica uno schema (http:// o https://), un FQDN e un percorso facoltativo. Terminare il percorso con / è facoltativo, ma consigliato. Il prefisso non deve includere parametri di query o frammenti come ? o #.
Ad esempio, https://media.example.com/videos corrisponde alle richieste di entrambi i seguenti elementi:
https://media.example.com/videos?video_id=138183&user_id=138138https://media.example.com/videos/137138595?quality=low
Il percorso del prefisso viene utilizzato come sottostringa di testo, non strettamente come percorso di directory.
Ad esempio, il prefisso https://example.com/data concede l'accesso a entrambi i seguenti elementi:
/data/file1/database
Per evitare questo 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
La procedura di convalida di un URL firmato è essenzialmente uguale a quella di generazione di un URL firmato. Ad esempio, supponiamo 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é, puoi verificare che corrisponda a SIGNATURE.
Supponiamo di voler convalidare un URL firmato che contiene 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 questo caso, puoi calcolare la firma per quanto segue:
URLPrefix=URL_PREFIX&Expires=EXPIRATION&KeyName=KEY_NAME
A questo punto puoi verificare che corrisponda a SIGNATURE.
Per i metodi di firma basati su URL, in cui la firma fa parte dei parametri di query o è incorporata come componente del percorso dell'URL, la firma e i parametri correlati vengono rimossi dall'URL prima che la richiesta venga inviata all'origine. In questo modo, la firma non causa problemi di routing quando l'origine gestisce la richiesta. Per convalidare queste richieste, puoi esaminare l'intestazione della richiesta x-client-request-url, che include l'URL della richiesta client originale (firmata) prima della rimozione dei componenti firmati.
Rimuovi l'accesso pubblico al bucket Cloud Storage
Affinché gli URL firmati proteggano 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 è rendere pubblici temporaneamente gli oggetti a scopo di test. Dopo aver attivato gli URL firmati, è importante rimuovere le autorizzazioni READ allUsers (e allAuthenticatedUsers, se applicabile) (ovvero il ruolo Identity and Access Management Storage Object Viewer) sul 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, ad esempio l'autorizzazione OWNER.
Per rimuovere l'accesso READ allUsers pubblico a un bucket Cloud Storage, esegui l'azione descritta in Rendi pubblicamente leggibili tutti gli oggetti in un bucket.
Distribuisci e utilizza gli URL firmati
L'URL restituito da Google Cloud CLI o prodotto dal tuo 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. Analogamente, assicurati di distribuire gli URL firmati tramite protocolli di trasporto sicuri come TLS/HTTPS.