Questa pagina fornisce una panoramica degli URL firmati e le istruzioni per utilizzarli con Cloud CDN. Gli URL firmati forniscono l'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 con firma 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 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 possieda può utilizzarlo per eseguire azioni specifiche (ad esempio la lettura di un oggetto) entro un determinato periodo di tempo.
Gli URL firmati supportano anche un parametro URLPrefix
facoltativo, che consente di fornire 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 istruzioni, consulta Utilizzo di Cloud CDN. Puoi configurare gli URL firmati su un backend prima di attivare Cloud CDN, ma non avranno alcun effetto finché Cloud CDN non sarà attivato.
Se necessario, esegui l'aggiornamento alla versione più recente 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 attivato Cloud CDN.
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 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
. Rifiuta le richieste con parametri non validi (o con formato non valido). - Quando l'applicazione rileva una firma non valida, assicurati che risponda con un codice di risposta
HTTP 403 (Unauthorized)
. I codici di rispostaHTTP 403
non sono memorizzabili nella cache. - Le risposte alle richieste firmate e non firmate vengono memorizzate nella cache separatamente, pertanto una risposta positiva a una richiesta firmata valida non viene mai utilizzata per soddisfare una 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 rimuovere l'accesso pubblico, in modo che Cloud Storage possa rifiutare le richieste per le quali manca una firma valida.
La seguente tabella riassume il comportamento.
La richiesta ha la firma | Hit della cache | Comportamento |
---|---|---|
No | No | Inoltra all'origine di backend. |
No | Sì | Pubblicazione dalla cache. |
Sì | No | Convalida la firma. Se valido, inoltra 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 le chiavi in base alle tue esigenze di sicurezza. Ogni backend può avere fino a tre chiavi configurate contemporaneamente. Ti consigliamo di ruotare periodicamente le chiavi eliminando la più vecchia, aggiungendo una nuova chiave e utilizzandola per firmare gli URL o i cookie.
Puoi utilizzare lo stesso nome della chiave in più servizi e bucket di backend perché ogni insieme 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 mantenerle al sicuro, perché chiunque abbia una delle tue chiavi può creare URL o cookie firmati accettati da Cloud CDN finché la chiave non viene eliminata da Cloud CDN. Le chiavi vengono archiviate sul computer su cui generi gli URL o i cookie firmati. Cloud CDN memorizza anche le chiavi per verificare le firme delle richieste.
Per mantenere le chiavi segrete, i valori delle chiavi non sono inclusi nelle risposte alle richieste dell'API. Se perdi una chiave, devi crearne una nuova.
Per creare una chiave di richiesta firmata:
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 dell'origine, fai clic sul pulsante Modifica.
- Nella sezione Nozioni di base sulle origini, 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 Rendimento 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 della chiave, seleziona Genera automaticamente. In alternativa, fai clic su Fammi inserire, quindi specifica un valore della 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 Tempo massimo di una voce della 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 specificato. 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 ulteriori informazioni, consulta
RFC 4648.
È fondamentale che la chiave sia fortemente casuale. Su un sistema UNIX-like, puoi
generare una chiave fortemente casuale e memorizzarla 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 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 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 a causa di un errore perché l'account di servizio per il riempimento della cache 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_NUM@cloud-cdn-fill.iam.gserviceaccount.com \ --role=roles/storage.objectViewer
Sostituisci PROJECT_NUM
con il numero del progetto e
BUCKET
con il 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 accade 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 Trovare l'ID progetto e il numero di progetto nella documentazione della guida della console Google Cloud.
Personalizzare il tempo massimo 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 nuova convalida è impostato dal flag signed-url-cache-max-age
, che
per impostazione predefinita è pari a un'ora e può essere modificato 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 per le richieste firmate
Per elencare le chiavi in un servizio o un bucket di backend, esegui uno dei seguenti comandi:
gcloud compute backend-services describe BACKEND_NAME
gcloud compute backend-buckets describe BACKEND_NAME
Eliminare le chiavi per le richieste firmate
Quando non è più necessario rispettare gli URL firmati da una determinata chiave, 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 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 scrivi autonomamente.
Se hai bisogno di molti URL firmati, il codice personalizzato offre un rendimento migliore.
gcloud
o alle API programmatiche, 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 corrisponde al valore calcolato da Cloud CDN.Creare 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 usare Google Cloud CLI o scrivere codice personalizzato utilizzando i seguenti esempi.
gcloud
Google Cloud CLI include un comando per la firma degli URL. Il comando implementa l'algoritmo descritto nella sezione relativa 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 della chiave codificato in base64url da KEY_FILE_NAME
e poi genera 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 di percorso. Ad esempio, http://example.com
non è valido, ma
https://example.com/
e https://example.com/whatever
sono entrambi URL validi.
Se viene specificato 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 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.TIME_UNTIL_EXPIRATION
Se non viene specificato il flag --validate
, 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.
Vai
Ruby
.NET
Java
Python
PHP
Creare programmaticamente URL firmati con un prefisso URL
Gli esempi di codice riportati di seguito mostrano come creare in modo programmatico URL firmati 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 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:
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
Expires
con la data e l'ora di scadenza richieste in ora UTC (il numero di secondi dal 1° gennaio 1970 alle ore 00:00:00 UTC). Per massimizzare la sicurezza, imposta il valore sul periodo di tempo più breve possibile per il tuo caso d'uso. Quanto più un URL firmato è valido, maggiore è il rischio che l'utente a cui lo fornisci lo condivida con altri, accidentalmente 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. È meglio utilizzare 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 in Creare 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 nell'URL firmato non venga modificata la maiuscola.
a. Esegui l'hash 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 di 16 byte, non la chiave con codifica base64url. Decodificalo se necessario.b. Utilizza base64url encode 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 di richiesta completo 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 diversi URL che corrispondono a URLPrefix
, evitando di dover creare una nuova
firma per ogni URL distinto.
Nell'esempio seguente, il testo evidenziato mostra i parametri che firmi. Come di consueto, Signature
viene aggiunto come parametro di query finale.
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 i parametri di ricerca, pertanto 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 include tutti i percorsi per i quali la firma deve essere valida.
Un URLPrefix
codifica uno schema (http://
o https://
), un FQDN e un
percorso facoltativo. Terminare il percorso con un /
è facoltativo, ma consigliato. Il prefisso non deve includere parametri di ricerca o frammenti come ?
o #
.
Ad esempio, https://media.example.com/videos
corrisponde alle richieste per 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 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 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 la stessa di quella per generare un URL firmato. Ad esempio, supponiamo che tu voglia 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
Poi puoi verificare che corrisponda a SIGNATURE
.
Supponiamo che tu voglia convalidare un URL firmato che contenga 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
Puoi quindi 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 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.
Rimuovere 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 gli oggetti
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 Visualizzatore oggetti Storage di Identity and Access Management) 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
su un bucket Cloud Storage,
esegui l'azione inversa 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 prodotto dal codice personalizzato può essere distribuito in base alle tue esigenze. Ti consigliamo di firmare solo gli URL HTTPS, perché questo protocollo 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.