URLs firmadas

En esta página, se proporciona una descripción general de las URL firmadas, que otorgan acceso por tiempo limitado a un recurso específico de Cloud Storage. Cualquier persona que cuente con la URL firmada la puede usar mientras esté activa, sin importar si tiene una Cuenta de Google. Para obtener información sobre cómo crear una URL firmada, consulta el proceso de firma de V4 con las herramientas de Cloud Storage y el proceso de firma de V4 con tu propio programa. Para obtener más información sobre otras maneras de controlar el acceso a los buckets y objetos, consulta la descripción general de control de acceso.

Descripción general

Una URL firmada es una URL que proporciona permisos y tiempo limitados para realizar una solicitud. Las URL firmadas contienen información de autenticación en tu string de consulta, lo que permite a los usuarios sin credenciales realizar acciones específicas en un recurso.

  • Cuando generas una URL firmada, debes especificar una cuenta que tenga los permisos suficientes para realizar la solicitud que realizará la URL firmada.

    • En la mayoría de los casos, es una cuenta de servicio.

    • En los casos en que crees tu propio programa para generar URLs firmadas, es posible usar una cuenta de usuario si tiene una clave HMAC asociada.

Después de generar una URL firmada, cualquier persona que la posea puede usarla para realizar acciones específicas, como leer un objeto, dentro de un período específico.

¿Cuándo debes usar una URL firmada?

En algunas situaciones, es posible que no desees solicitarles a tus usuarios una Cuenta de Google para acceder a Cloud Storage, pero deseas controlar el acceso mediante la lógica específica de tu aplicación. La forma típica de abordar este caso práctico es proporcionar una URL firmada a un usuario, que le otorga acceso de lectura, escritura o eliminación a ese recurso por un tiempo limitado. Debes especificar una hora de vencimiento cuando creas la URL firmada. Cualquier usuario que conozca la URL puede acceder al recurso hasta que se alcance la fecha de vencimiento de la URL o se cambie la clave usada para firmar la URL.

Los usos más comunes de las URL firmadas son las cargas y descargas, debido a que, en estas solicitudes, los datos de los objetos se transfieren entre los solicitantes y Cloud Storage. En la mayoría del resto de los casos, como copiar, componer o borrar objetos, editar metadatos o crear una URL firmada y otorgarla a alguien para que la use es un paso adicional innecesario. En cambio, debes considerar un diseño en el que la entidad responsable de crear la URL firmada realice directamente la solicitud deseada a Cloud Storage.

Opciones para generar una URL firmada

Cloud Storage admite varios métodos para generar una URL firmada:

  • Firma V4 con autenticación de cuenta de servicio: este mecanismo de firma se describe a continuación.

  • Firma con autenticación de HMAC: si eres usuario de Amazon Simple Storage Service (Amazon S3), puedes usar tus flujos de trabajo existentes para generar URL firmadas para Cloud Storage. Solo especifica los recursos de Cloud Storage, señala el host storage.googleapis.com y usa las credenciales de HMAC de Cloud Storage en el proceso de generar la URL firmada.

Ejemplo de URL firmada

El siguiente es un ejemplo de una URL firmada que se creó después del proceso de firma de V4 con autenticación de cuenta de servicio:

https://storage.googleapis.com/example-bucket/cat.jpeg?X-Goog-Algorithm=
GOOG4-RSA-SHA256&X-Goog-Credential=example%40example-project.iam.gserviceaccount
.com%2F20181026%2Fus-central1%2Fstorage%2Fgoog4_request&X-Goog-Date=20181026T18
1309Z&X-Goog-Expires=900&X-Goog-SignedHeaders=host&X-Goog-Signature=247a2aa45f16
9edf4d187d54e7cc46e4731b1e6273242c4f4c39a1d2507a0e58706e25e3a85a7dbb891d62afa849
6def8e260c1db863d9ace85ff0a184b894b117fe46d1225c82f2aa19efd52cf21d3e2022b3b868dc
c1aca2741951ed5bf3bb25a34f5e9316a2841e8ff4c530b22ceaa1c5ce09c7cbb5732631510c2058
0e61723f5594de3aea497f195456a2ff2bdd0d13bad47289d8611b6f9cfeef0c46c91a455b94e90a
66924f722292d21e24d31dcfb38ce0c0f353ffa5a9756fc2a9f2b40bc2113206a81e324fc4fd6823
a29163fa845c8ae7eca1fcf6e5bb48b3200983c56c5ca81fffb151cca7402beddfc4a76b13344703
2ea7abedc098d2eb14a7

Esta URL firmada proporcionó acceso para leer el objeto cat.jpeg en el bucket example-bucket. Los parámetros de búsqueda que la convierten en una URL firmada son los siguientes:

  • X-Goog-Algorithm: el algoritmo usado para firmar la URL.

  • X-Goog-Credential: información sobre las credenciales usadas para crear la URL firmada.

  • X-Goog-Date: la fecha y la hora en que se puede usar la URL firmada en el formato básico ISO 8601YYYYMMDD'T'HHMMSS'Z'.

  • X-Goog-Expires: la cantidad de tiempo que la URL firmada siguió siendo válida, medida en segundos a partir del valor en X-Goog-Date. En este ejemplo, la URL firmada caduca en 15 minutos. El valor de vencimiento más largo es 604800 segundos (7 días).

  • X-Goog-SignedHeaders: encabezados que debían incluirse como parte de cualquier solicitud que usara la URL firmada.

  • X-Goog-Signature: la string de autenticación que permitió que las solicitudes que usan esta URL firmada accedan a cat.jpeg.

Usa URL firmadas con cargas reanudables

Cuando trabajas con cargas reanudables, solo debes crear y usar una URL firmada para la solicitud POST que inicia la carga. Esta solicitud inicial muestra un URI de sesión que se usa en solicitudes PUT posteriores para subir los datos. Debido a que el URI de sesión actúa como un token de autenticación, las solicitudes PUT no usan ninguna URL firmada.

Una ventaja de las cargas reanudables es que permiten que el servidor realice la solicitud de inicio, lo que evita la necesidad de que los clientes tengan que lidiar con las URL firmadas. Sin embargo, hay algunas consideraciones que debe tener en cuenta:

  • Cualquiera puede contener el URI de sesión para subir datos. Asegúrate de transmitir el URI de sesión a través de HTTPS cuando se lo entregues a un cliente.

  • Las cargas reanudables se fijan en la región de la solicitud inicial. Para evitar cargas lentas, si el servidor y el cliente están en lugares geográficamente distantes, haz que el servidor construya y firme la solicitud inicial POST y, luego, entrega la URL firmada al cliente para que la carga se inicie desde su ubicación.

Consideraciones de URL firmadas

Cuando trabajes con URL firmadas, ten en cuenta lo siguiente:

  • Las URL firmadas solo se pueden usar para acceder a recursos de Cloud Storage a través de extremos de la API de XML.

  • Por lo general, las URL firmadas se pueden realizar para cualquier solicitud a la API de XML. Sin embargo, hay dos excepciones:

    • Las URL firmadas que usan firmas V4 no se pueden usar en solicitudes cuyo cuerpo usa codificación fragmentada.

    • Por el momento, las bibliotecas cliente de Cloud Storage para Node.js solo pueden crear URL firmadas para objetos individuales. Por ejemplo, no se pueden usar para crear URL firmadas para enumerar objetos en un bucket.

  • Cuando especificas las credenciales, se recomienda que identifiques tu cuenta de servicio mediante su dirección de correo electrónico. Sin embargo, también se admite el uso del ID de la cuenta de servicio.

  • Asegúrate de omitir el encabezado de autorización de cualquier solicitud que use una URL firmada. Si se usan ambas, Cloud Storage puede autenticarse en las credenciales proporcionadas en el encabezado, en lugar de la URL firmada. Esto podría permitir más acceso a los recursos de los que querías.

Solicitudes canónicas

Las URL firmadas usan solicitudes canónicas como parte de la información codificada en su parámetro de string de consulta X-Goog-Signature. Cuando creas una URL firmada con las herramientas de Cloud Storage, la solicitud canónica requerida se crea y, luego, incorpora automáticamente. Sin embargo, cuando creas una URL firmada con tu propio programa, debes definir la solicitud canónica tú mismo y usarla para crear una firma.

Alcance de la credencial

El permiso de la credencial aparece en la string que se debe firmar y en el parámetro de string de consulta X-Goog-Credential.

¿Qué sigue?