URL firmadas

En esta página, se proporciona una descripción general de las URL firmadas, que son un mecanismo para autenticar las strings de las consultas destinado a los depósitos y objetos. Las URL firmadas proporcionan una forma de otorgar acceso de lectura o escritura por tiempo limitado a cualquier persona que posea la URL, sin importar si tiene una Cuenta de Google. Para aprender cómo crear una URL firmada, consulta Crea URL firmadas con gsutil y Crea URL firmadas con un programa. Para obtener información sobre otras formas de controlar el acceso a los depósitos y objetos, consulta Descripción general del control de acceso.

¿Cuándo debes usar una URL firmada?

En algunas situaciones, es posible que no desees que tus usuarios necesiten una Cuenta de Google para acceder a Cloud Storage, pero quieres 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 borrado a ese recurso por un tiempo limitado. Cualquiera que conozca la URL puede acceder al recurso hasta que la URL se venza. Debes especificar el tiempo de vencimiento en la string de la consulta que se firmará.

Usa URL firmadas con cargas reanudables

Si tus usuarios solo suben recursos (de escritura) a un depósito de acceso controlado, puedes usar la funcionalidad de cargas reanudables de Cloud Storage para requerir solo una URL firmada. Esta URL firmada es parte de la solicitud inicial POST, durante la cual no se carga ningún dato. Se muestra un URI de sesión desde la solicitud inicial POST que se puede usar en solicitudes PUT posteriores para subir datos. Debido a que el URI de sesión es, en efecto, un token de autenticación, no es necesario que se firmen las solicitudes PUT. El servidor puede realizar la solicitud POST, lo cual evita que los clientes deban usar URL firmadas o una Cuenta de Google.

Las cargas reanudables se fijan en la región en la que comienzan. Por ejemplo, si creas una URL de carga reanudable en EE.UU. y se la entregas a un cliente en Asia, la carga aún se realiza en EE.UU. Realizar una carga reanudable en una región donde no se inició puede generar cargas lentas. Para evitar esto, puedes hacer que el servidor cree y firme la solicitud inicial POST, pero luego debes entregar la URL firmada al cliente para que la carga se inicie desde su ubicación. Después del inicio, el cliente puede usar el URI de sesión resultante de forma normal para realizar solicitudes PUT que no necesitan firmarse.

Si usas instancias de Compute Engine con procesos que POST a Cloud Storage para iniciar una carga reanudable, entonces debes usar instancias de Compute Engine en las mismas ubicaciones que tus depósitos de Cloud Storage. Puedes usar un servicio de IP geográfico para seleccionar la región de Compute Engine a la que enrutarás las solicitudes de los clientes, lo que te ayuda a tener el tráfico ubicado en una región geográfica.

Componentes de la string que necesitan firma

Cuando creas una URL firmada con un programa, tu programa crea una string que será firmada. Esta string debe definirse en tu programa de la siguiente manera:

StringToSign = HTTP_Verb + "\n" +
               Content_MD5 + "\n" +
               Content_Type + "\n" +
               Expiration + "\n" +
               Canonicalized_Extension_Headers +
               Canonicalized_Resource

Los componentes que forman esta estructura se describen en la siguiente tabla:

Componente de la string Ejemplo Descripción
HTTP_Verb GET Obligatorio. El verbo HTTP que se usará con la URL firmada.

Nota: El verbo HTTP POST no se admite en strings de URL firmadas, excepto en los casos que se indicaron con anterioridad. Puedes usar POST para definir documentos de políticas firmados, que especifican las características de los objetos que se pueden subir a un depósito. Obtén más información en la documentación objetos POST.

Content_MD5 rmYdCNHKFXam78uCt7xQLw== Opcional. El valor de resumen de MD5 en Base64. Si proporcionas esto en la string, el cliente (por lo general, un navegador) debe proporcionar este encabezado HTTP con este mismo valor en su solicitud.
Content_Type text/plain Según sea necesario. Si proporcionas un content-type, el cliente (navegador) debe proporcionar este conjunto de encabezados HTTP con el mismo valor.
Expiration 1388534400 Obligatorio. Esta es la marca de tiempo (representada como el número de segundos desde la época Unix del UTC 00:00:00 el 1 de enero de 1970) cuando se vence la firma. El servidor rechaza cualquier solicitud recibida después de esta marca de tiempo.
Canonicalized_Extension_Headers x-goog-acl:public-read\nx-goog-meta-foo:bar,baz\n Según sea necesario. El servidor verifica a fin de asegurarse de que el cliente proporcione valores coincidentes en las solicitudes con la URL firmada. Si deseas obtener información sobre cómo crear encabezados canónicos para firmar, consulta encabezados de extensión canónicos.
Canonicalized_Resource /bucket/objectname Obligatorio. El recurso que se aborda en la URL. Para obtener más detalles, consulta Recursos canónicos.

Firma strings con el servicio de App Identity de App Engine

Cuando creas una URL firmada con un programa, puedes firmar la string desde tu programa o desde una aplicación de Google App Engine con el servicio de identidad de App Engine, que usa las credenciales de la cuenta de servicio de App Engine. Por ejemplo, si usas la API de App Identity para Python, puedes hacer lo siguiente:

  • Usar google.appengine.api.app_identity.sign_blob() para firmar los bytes desde tu string creada, si proporcionas la Signature que necesitas cuando establezcas la URL firmada

  • Usar google.appengine.api.app_identity.get_service_account_name() para recuperar el nombre de la cuenta de servicio, que es el GoogleAccessId que necesitarás cuando establezcas la URL firmada

Si quieres obtener asistencia en otros lenguajes, consulta Descripción general de la API de App Identity para Java, Descripción general de la API de App Identity para PHP y Descripción general de la API de App Identity para las funciones de Go.

El servicio de App Identity rota las claves privadas cuando firma los BLOB. Las URL firmadas generadas desde el servicio de App Identity son útiles durante una hora como mínimo y se usan mejor para el acceso a los recursos de corta duración.

Encabezados de extensión canónica

Cuando creas una URL firmada con un programa, creas la parte del mensaje de los encabezados de extensión canónica mediante la concatenación de todos los encabezados de extensión (personalizados) que comienzan con x-goog-. Sin embargo, no puedes realizar una concatenación simple. Ten en cuenta el siguiente algoritmo cuando crees los encabezados:

  1. Crea todos los nombres de encabezados personalizados en minúsculas.

  2. Ordena todos los encabezados personalizados por nombre de encabezado con un orden lexicográfico por el valor de puntos de código.

  3. Si están presentes, quita los encabezados x-goog-encryption-key y x-goog-encryption-key-sha256. Estos encabezados contienen información sensible que no se debe incluir en la string para firmar; sin embargo, estos encabezados se deben usar en cualquier solicitud que use la URL firmada que se generó.

  4. Borra los nombres de encabezados duplicados. Puedes hacerlo si creas un nombre de encabezado con una lista de valores separada por comas. Asegúrate de que no haya espacios en blanco entre los valores y de que el orden de la lista separada por comas coincida con el orden en que aparecen los encabezados en tu solicitud. Para obtener más información, consulta la sección 3.2 de RFC 7230.

  5. Reemplaza cualquier espacio en blanco plegable o salto de línea (CRLF o LF) con un solo espacio. Para obtener más información sobre el plegado de espacios en blanco, consulta RFC 7230, sección 3.2.4.

  6. Quita los espacios en blanco alrededor de los dos puntos que aparecen después del nombre del encabezado.

  7. Agrega un salto de línea “\n” (U + 000A) a cada encabezado personalizado.

  8. Concatena todos los encabezados personalizados.

Recursos canónicos

Cuando creas una URL firmada con un programa, creas la parte del mensaje del recurso canonicalizado mediante la concatenación de la ruta del recurso (depósito, objeto y subrecurso) en el que actúa la solicitud. Ten en cuenta lo siguiente cuando crees el recurso:

  • El recurso canónico es todo lo que sigue al nombre del host. Por ejemplo, si la URL de Cloud Storage es https://storage.googleapis.com/example-bucket/cat-pics/tabby.jpeg, entonces el recurso canónico es /example-bucket/cat-pics/tabby.jpeg.

  • Si la solicitud tiene alcance en un subrecurso, como ?cors, agrega este subrecurso, incluye el signo de interrogación al final de la string.

  • Asegúrate de copiar la ruta de solicitud HTTP de forma literal: es decir, debes incluir toda la codificación de URL (signos de porcentaje) en la string que crees. Además, asegúrate de incluir solo los parámetros de la string de la consulta que designan los subrecursos (como cors). No debes incluir parámetros de la string de la consulta, como ?prefix, ?max-keys, ?marker y ?delimiter.

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Si necesitas ayuda, visita nuestra página de asistencia.