En esta página se ofrece una descripción general de las URLs firmadas y se explica cómo usarlas con Cloud CDN. Las URLs firmadas proporcionan acceso a recursos durante un tiempo limitado a cualquier usuario que disponga de dicha URL, independientemente de si tiene una cuenta de Google o no.
Una URL firmada es una URL que proporciona permiso y tiempo limitados para hacer una solicitud. Las URLs firmadas contienen información de autenticación en sus cadenas de consulta, lo que permite a los usuarios sin credenciales realizar acciones específicas en un recurso. Cuando generas una URL firmada, especificas un usuario o una cuenta de servicio que debe tener permisos suficientes para hacer la solicitud asociada a la URL.
Una vez que hayas generado una URL firmada, cualquier persona que la tenga podrá usarla para realizar las acciones especificadas (como leer un objeto) durante un periodo determinado.
Las URLs firmadas también admiten un parámetro URLPrefix
opcional, que le permite proporcionar acceso a varias URLs basadas en un prefijo común.
Si quieres limitar el acceso a un prefijo de URL específico, te recomendamos que utilices cookies firmadas.
Antes de empezar
Antes de usar URLs firmadas, haga lo siguiente:
Asegúrate de que Cloud CDN esté habilitado. Para obtener instrucciones, consulta el artículo Usar Cloud CDN. Puedes configurar URLs firmadas en un backend antes de habilitar Cloud CDN, pero no tendrán ningún efecto hasta que Cloud CDN esté habilitado.
Si es necesario, actualiza a la versión más reciente de la CLI de Google Cloud:
gcloud components update
Para obtener una descripción general, consulta URLs y cookies firmadas.
Configurar claves de solicitud firmada
Para crear claves para sus URLs firmadas o cookies firmadas, debe seguir varios pasos, que se describen en las siguientes secciones.
Cuestiones sobre seguridad
Cloud CDN no valida las solicitudes en las siguientes circunstancias:
- La solicitud no está firmada.
- El servicio de backend o el segmento de backend de la solicitud no tiene habilitada la CDN de Cloud.
Las solicitudes firmadas deben validarse siempre en el origen antes de servir la respuesta. Esto se debe a que los orígenes se pueden usar para servir una combinación de contenido firmado y sin firmar, y a que un cliente puede acceder al origen directamente.
- Cloud CDN no bloquea las solicitudes que no tienen el parámetro de consulta
Signature
ni la cookie HTTPCloud-CDN-Cookie
. Rechaza las solicitudes con parámetros no válidos (o con un formato incorrecto). - Cuando tu aplicación detecte una firma no válida, asegúrate de que responda con el código de respuesta
HTTP 403 (Unauthorized)
. Los códigos de respuestaHTTP 403
no se pueden almacenar en caché. - Las respuestas a solicitudes firmadas y sin firmar se almacenan en caché por separado, por lo que una respuesta correcta a una solicitud firmada válida nunca se utiliza para servir una solicitud sin firmar.
- Si tu aplicación envía un código de respuesta que se puede almacenar en caché a una solicitud no válida, es posible que se rechacen incorrectamente solicitudes válidas en el futuro.
En el caso de los back-ends de Cloud Storage, asegúrate de eliminar el acceso público para que Cloud Storage pueda rechazar las solicitudes que no tengan una firma válida.
En la siguiente tabla se resume el comportamiento.
Request has signature | Resultado en caché | Comportamiento |
---|---|---|
No | No | Reenvía la solicitud al origen del backend. |
No | Sí | Servir desde la caché. |
Sí | No | Validar firma. Si es válido, reenvíalo al origen backend. |
Sí | Sí | Validar firma. Si es válido, se sirve desde la caché. |
Crear claves de solicitud firmadas
Para habilitar la compatibilidad con las URLs y las cookies firmadas de Cloud CDN, debes crear una o varias claves en un servicio de backend o un segmento de backend (o ambos) que tenga habilitado Cloud CDN.
En cada servicio o segmento de backend, puedes crear y eliminar claves según tus necesidades de seguridad. Cada backend puede tener hasta tres claves configuradas a la vez. Te recomendamos que rotes periódicamente tus claves eliminando la más antigua, añadiendo una nueva y usando la nueva clave al firmar URLs o cookies.
Puedes usar el mismo nombre de clave en varios servicios de backend y segmentos de backend, ya que cada conjunto de claves es independiente de los demás. Los nombres de las claves pueden tener hasta 63 caracteres. Para asignar nombres a las claves, utiliza los caracteres A-Z, a-z, 0-9, _ (guion bajo) y - (guion).
Cuando crees claves, asegúrate de que estén protegidas, ya que cualquier persona que tenga una de tus claves podrá crear URLs firmadas o cookies firmadas que Cloud CDN acepte hasta que se elimine la clave de Cloud CDN. Las claves se almacenan en el ordenador en el que generas las URLs o las cookies firmadas. Cloud CDN también almacena las claves para verificar las firmas de las solicitudes.
Para mantener las claves en secreto, los valores de las claves no se incluyen en las respuestas a ninguna solicitud de API. Si pierdes una clave, debes crear otra.
Para crear una clave de solicitud firmada, sigue estos pasos.
Consola
- En la Google Cloud consola, ve a la página Cloud CDN.
- Haga clic en el nombre del origen al que quiera añadir la clave.
- En la página Detalles del origen, haga clic en el botón Editar.
- En la sección Información básica del origen, haz clic en Siguiente para abrir la sección Reglas de host y ruta.
- En la sección Reglas de host y ruta, haga clic en Siguiente para abrir la sección Rendimiento de la caché.
- En la sección Contenido restringido, selecciona Restringir acceso mediante URLs y cookies firmadas.
Haz clic en Añadir clave de firma.
- Especifica un nombre único para la nueva clave de firma.
En la sección Método de creación de claves, seleccione Generar automáticamente. También puedes hacer clic en Quiero introducirla y especificar un valor de clave de firma.
En el caso de la primera opción, copia el valor de la clave de firma generada automáticamente en un archivo privado que puedes usar para crear URLs firmadas.
Haz clic en Listo.
En la sección Antigüedad máxima de la entrada de caché, introduce un valor y, a continuación, selecciona una unidad de tiempo.
Haz clic en Listo.
gcloud
La herramienta de línea de comandos gcloud
lee las claves de un archivo local que especifiques. El archivo de claves debe crearse generando 128 bits aleatorios, codificándolos con Base64 y, a continuación, sustituyendo el carácter +
por -
y el carácter /
por _
. Para obtener más información, consulta RFC 4648.
Es fundamental que la clave sea aleatoria. En un sistema de tipo UNIX, puedes generar una clave aleatoria segura y almacenarla en el archivo de claves con el siguiente comando:
head -c 16 /dev/urandom | base64 | tr +/ -_ > KEY_FILE_NAME
Para añadir la clave a un servicio backend, sigue estos pasos:
gcloud compute backend-services \ add-signed-url-key BACKEND_NAME \ --key-name KEY_NAME \ --key-file KEY_FILE_NAME
Para añadir la clave a un backend, sigue estos pasos:
gcloud compute backend-buckets \ add-signed-url-key BACKEND_NAME \ --key-name KEY_NAME \ --key-file KEY_FILE_NAME
Configurar permisos de Cloud Storage
Si usas Cloud Storage y has restringido quién puede leer los objetos, debes dar permiso a Cloud CDN para que lea los objetos añadiendo la cuenta de servicio de Cloud CDN a las ACLs de Cloud Storage.
No es necesario que crees la cuenta de servicio. La cuenta de servicio se crea automáticamente la primera vez que añades una clave a un backend de un proyecto.
Antes de ejecutar el siguiente comando, añade al menos una clave a un backend de tu proyecto. De lo contrario, el comando fallará y se producirá un error porque la cuenta de servicio de relleno de caché de Cloud CDN no se crea hasta que añadas una o más claves al proyecto.
.gcloud storage buckets add-iam-policy-binding gs://BUCKET \ --member=serviceAccount:service-PROJECT_NUM@cloud-cdn-fill.iam.gserviceaccount.com \ --role=roles/storage.objectViewer
Sustituye PROJECT_NUM
por el número de tu proyecto y BUCKET
por tu segmento de almacenamiento.
La cuenta de servicio de Cloud CDN
service-PROJECT_NUM@cloud-cdn-fill.iam.gserviceaccount.com
no aparece en la lista de cuentas de servicio de tu proyecto. Esto se debe a que la cuenta de servicio de Cloud CDN es propiedad de Cloud CDN, no de tu proyecto.
Para obtener más información sobre los números de proyecto, consulta el artículo Buscar el ID y el número de proyecto de la documentación de ayuda de la consola de Google Cloud .
Personalizar el tiempo máximo de la caché
La CDN de Cloud almacena en caché las respuestas de las solicitudes firmadas, independientemente del encabezado Cache-Control
del backend. El tiempo máximo que se pueden almacenar en caché las respuestas sin volver a validarlas se define mediante la marca signed-url-cache-max-age
, que tiene un valor predeterminado de una hora y se puede modificar como se muestra aquí.
Para definir el tiempo máximo de almacenamiento en caché de un servicio de backend o un segmento de backend, ejecuta uno de los siguientes comandos:
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
Lista de nombres de claves de solicitudes firmadas
Para enumerar las claves de un servicio o un segmento de backend, ejecuta uno de los siguientes comandos:
gcloud compute backend-services describe BACKEND_NAME
gcloud compute backend-buckets describe BACKEND_NAME
Eliminar claves de solicitud firmada
Cuando las URLs firmadas por una clave concreta ya no deban aceptarse, ejecuta uno de los siguientes comandos para eliminar esa clave del servicio backend o del backend del contenedor:
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
Firmar URLs
El último paso es firmar las URLs y distribuirlas. Puedes firmar URLs con el comando gcloud compute sign-url
o con código que escribas tú.
Si necesitas muchas URLs firmadas, el código personalizado ofrece un mejor rendimiento.
Crear URLs firmadas
Sigue estas instrucciones para crear URLs firmadas con el comando gcloud compute sign-url
. En este paso se da por hecho que ya has creado las claves.
Consola
No puedes crear URLs firmadas con la consola Google Cloud . Puedes usar la CLI de Google Cloud o escribir código personalizado con los siguientes ejemplos.
gcloud
La CLI de Google Cloud incluye un comando para firmar URLs. El comando implementa el algoritmo descrito en la sección sobre escribir tu propio código.
gcloud compute sign-url \ "URL" \ --key-name KEY_NAME \ --key-file KEY_FILE_NAME \ --expires-in TIME_UNTIL_EXPIRATION \ [--validate]
Este comando lee y decodifica el valor de clave codificado en base64url de KEY_FILE_NAME
y, a continuación, genera una URL firmada que puedes usar para las solicitudes GET
o HEAD
de la URL dada.
Por ejemplo:
gcloud compute sign-url \ "https://example.com/media/video.mp4" \ --key-name my-test-key \ --expires-in 30m \ --key-file sign-url-key-file
El URL
debe ser una URL válida que tenga un componente de ruta. Por ejemplo, http://example.com
no es válido, pero https://example.com/
y https://example.com/whatever
sí lo son.
Si se proporciona la marca opcional --validate
, este comando envía una solicitud HEAD
con la URL resultante e imprime el código de respuesta HTTP. Si la URL firmada es correcta, el código de respuesta es el mismo que el código de resultado enviado por tu backend. Si el código de respuesta no es el mismo, vuelve a comprobar KEY_NAME
y el contenido del archivo especificado, y asegúrate de que el valor de TIME_UNTIL_EXPIRATION
sea de al menos varios segundos.
Si no se indica la marca --validate
, no se verifican los siguientes elementos:
- Las entradas
- La URL generada
- La URL firmada generada
Crear URLs firmadas mediante programación
En los siguientes ejemplos de código se muestra cómo crear URLs firmadas mediante programación.
Go
Ruby
.NET
Java
Python
PHP
Crear URLs firmadas de forma programática con un prefijo de URL
En los siguientes ejemplos de código se muestra cómo crear de forma programática URLs firmadas con un prefijo de URL.
Go
Java
Python
Generar URLs firmadas personalizadas
Cuando escribas tu propio código para generar URLs firmadas, tu objetivo será crear URLs con el siguiente formato o algoritmo. Todos los parámetros de la URL distinguen entre mayúsculas y minúsculas y deben estar en el orden que se muestra:
https://example.com/foo?Expires=EXPIRATION&KeyName=KEY_NAME&Signature=SIGNATURE
Para generar URLs firmadas, sigue estos pasos:
Asegúrate de que la URL de firma no tenga un parámetro de consulta
Signature
.Determina cuándo caduca la URL y añade un parámetro de consulta
Expires
con la hora de vencimiento necesaria en UTC (el número de segundos transcurridos desde el 1 de enero de 1970 a las 00:00:00 UTC). Para maximizar la seguridad, define el valor en el periodo más breve posible para tu caso práctico. Cuanto más tiempo sea válida una URL firmada, mayor será el riesgo de que el usuario al que se la proporciones la comparta con otros usuarios, ya sea por error o de otra forma.Define el nombre de la clave. La URL debe estar firmada con una clave del servicio de backend o del bucket de backend que la proporcione. Es mejor usar la clave añadida más recientemente para cambiar la clave. Añade la clave a la URL añadiendo
&KeyName=KEY_NAME
. SustituyeKEY_NAME
por el nombre de la clave elegida que has creado en Crear claves de solicitud firmadas.Firma la URL. Crea la URL firmada siguiendo estos pasos. Asegúrate de que los parámetros de consulta estén en el orden que se muestra inmediatamente antes del paso 1 y de que no se modifiquen las mayúsculas ni las minúsculas en la URL firmada.
a. Cifra con hash toda la URL (incluidos
http://
ohttps://
al principio y&KeyName...
al final) con HMAC-SHA1 mediante la clave secreta que corresponda al nombre de clave elegido anteriormente. Usa la clave secreta sin procesar de 16 bytes, no la clave codificada en base64url. Descifrarlo si es necesario.b. Usa base64url encode para codificar el resultado.
c. Añade
&Signature=
a la URL, seguido de la firma codificada. No convierta los caracteres=
finales de la firma a su forma codificada como porcentaje,%3D
.
Usar prefijos de URL para URLs firmadas
En lugar de firmar la URL de solicitud completa con los parámetros de consulta Expires
y KeyName
, puede firmar solo los parámetros de consulta URLPrefix
, Expires
y KeyName
. De esta forma, se puede reutilizar literalmente una combinación determinada de parámetros de consulta URLPrefix
, Expires
, KeyName
y Signature
en varias URLs que coincidan con URLPrefix
, lo que evita tener que crear una firma nueva para cada URL distinta.
En el ejemplo siguiente, el texto destacado muestra los parámetros que firmas. El Signature
se añade como parámetro de consulta final, como de costumbre.
https://media.example.com/videos/id/master.m3u8?userID=abc123&starting_profile=1&URLPrefix=aHR0cHM6Ly9tZWRpYS5leGFtcGxlLmNvbS92aWRlb3Mv&Expires=1566268009&KeyName=mySigningKey&Signature=8NBSdQGzvDftrOIa3WHpp646Iis=
A diferencia de cuando se firma una URL de solicitud completa, al firmar con URLPrefix
no se firma ningún parámetro de consulta, por lo que se pueden incluir libremente en la URL. Además, a diferencia de las firmas de URL de solicitud completas, esos parámetros de consulta adicionales pueden aparecer tanto antes como después de los parámetros de consulta que componen la firma. Por lo tanto, la siguiente también es una URL válida con un prefijo de URL firmada:
https://media.example.com/videos/id/master.m3u8?userID=abc123&URLPrefix=aHR0cHM6Ly9tZWRpYS5leGFtcGxlLmNvbS92aWRlb3Mv&Expires=1566268009&KeyName=mySigningKey&Signature=8NBSdQGzvDftrOIa3WHpp646Iis=&starting_profile=1
URLPrefix
indica un prefijo de URL codificado en base64 seguro para URLs que abarca todas las rutas para las que debe ser válida la firma.
Un URLPrefix
codifica un esquema (http://
o https://
), un FQDN y una ruta opcional. Terminar la ruta con una /
es opcional, pero recomendable. El prefijo no debe incluir parámetros de consulta ni fragmentos, como ?
o #
.
Por ejemplo, https://media.example.com/videos
coincide con las solicitudes de los dos elementos siguientes:
https://media.example.com/videos?video_id=138183&user_id=138138
https://media.example.com/videos/137138595?quality=low
La ruta del prefijo se usa como una subcadena de texto, no como una ruta de directorio estricta.
Por ejemplo, el prefijo https://example.com/data
concede acceso a lo siguiente:
/data/file1
/database
Para evitar este error, te recomendamos que termines todos los prefijos con /
, a menos que quieras terminar el prefijo con un nombre de archivo parcial, como https://media.example.com/videos/123
, para conceder acceso a lo siguiente:
/videos/123_chunk1
/videos/123_chunk2
/videos/123_chunkN
Si la URL solicitada no coincide con la URLPrefix
, Cloud CDN rechaza la solicitud y devuelve un error HTTP 403
al cliente.
Validar URLs firmadas
El proceso de validación de una URL firmada es esencialmente el mismo que el de generar una URL firmada. Por ejemplo, supongamos que quiere validar la siguiente URL firmada:
https://example.com/PATH?Expires=EXPIRATION&KeyName=KEY_NAME&Signature=SIGNATURE
Puede usar la clave secreta denominada por KEY_NAME
para generar de forma independiente la firma de la siguiente URL:
https://example.com/PATH?Expires=EXPIRATION&KeyName=KEY_NAME
A continuación, puedes verificar que coincida con SIGNATURE
.
Supongamos que quieres validar una URL firmada que tiene un URLPrefix
, como se muestra a continuación:
https://example.com/PATH?URLPrefix=URL_PREFIX&Expires=EXPIRATION&KeyName=KEY_NAME&Signature=SIGNATURE
Primero, comprueba que el valor decodificado en Base64 de URL_PREFIX
es un prefijo de https://example.com/PATH
. Si es así, puedes calcular la firma de lo siguiente:
URLPrefix=URL_PREFIX&Expires=EXPIRATION&KeyName=KEY_NAME
A continuación, puedes verificar que coincida con SIGNATURE
.
En los métodos de firma basados en URLs, en los que la firma forma parte de los parámetros de consulta o se inserta como un componente de la ruta de la URL, la firma y los parámetros relacionados se eliminan de la URL antes de que se envíe la solicitud al origen. De esta forma, se evita que la firma cause problemas de enrutamiento cuando el origen gestione la solicitud. Para validar estas solicitudes, puede inspeccionar el encabezado de solicitud x-client-request-url
, que incluye la URL de solicitud del cliente original (firmada) antes de que se eliminen los componentes firmados.
Retira el acceso público al segmento de Cloud Storage
Para que las URLs firmadas protejan el contenido correctamente, es importante que el servidor de origen no conceda acceso público a ese contenido. Cuando se usa un segmento de Cloud Storage, una práctica habitual es hacer que los objetos sean públicos temporalmente con fines de prueba. Después de habilitar las URLs firmadas, es importante quitar los permisos de lectura allUsers
(y allAuthenticatedUsers
, si procede) (es decir, el rol de gestión de identidades y accesos Storage Object Viewer) del segmento.
Después de inhabilitar el acceso público al segmento, los usuarios individuales podrán seguir accediendo a Cloud Storage sin URLs firmadas si tienen permiso de acceso, como el permiso OWNER.
Para quitar el acceso de allUsers
LECTURA público a un segmento de Cloud Storage, invierte la acción descrita en Hacer que todos los objetos de un segmento se puedan leer públicamente.
Distribuir y usar URLs firmadas
La URL devuelta por la CLI de Google Cloud o generada por tu código personalizado se puede distribuir según tus necesidades. Te recomendamos que solo firmes URLs HTTPS, ya que HTTPS proporciona un transporte seguro que evita que se intercepte el Signature
componente de la URL firmada. Del mismo modo, asegúrate de distribuir las URLs firmadas a través de protocolos de transporte seguros, como TLS o HTTPS.