El almacenamiento es una cuestión que, si bien básica, también es vital a la hora de entender la infraestructura en Cloud. Una MV en Azure se sustenta no solo sobre unos componentes de computación (CPU y RAM principalmente), sino que necesariamente, requerimos de una unidad de almacenamiento donde se encuentre el sistema operativo. Esto hace del almacenamiento otro aspecto inevitable y relevante dentro de la infraestructura Cloud.

Pero el almacenamiento Cloud no solo nos sirve para contener el sistema operativo de nuestras máquinas virtuales, sino que Azure ofrece tipos de almacenamiento más variados para según qué casos: para comunicar partes de la infraestructura, para aplicaciones que despleguemos en Cloud, para bases de datos, y para archivos en general. Todo esto cabe dentro del servicio que Azure denomina “cuenta de almacenamiento”, pero para no entrar a explicar cada tipo de almacenamiento, nos vamos a centrar en el tipo que nos interesa, el blob.

BLOB significa Binary Large Object, y es como se denomina a los datos no estructurados (es decir, no tipificados como una tabla) que puedan alcanzar pesos grandes, hablamos de megabytes, gigabytes e incluso terabytes.

Una vez “paralelizamos” la idea de “blob” a la idea de “archivo”, tenemos que organizar estos blobs de algún modo. La forma de hacerlo es en “contenedores”, que no hay que confundir con los “containers” que acostumbramos a ver en infraestructuras basadas en Docker.

Queda entonces un esquema en el que la cuenta de almacenamiento tiene contenedores, y dentro de los contenedores, están los blobs. Podríamos subir carpetas como blobs, pero Azure no las comprende como “carpetas” en sí, sino como otro blob, de forma que la gestión de permisos a estos recursos se puede hacer a esos tres niveles: Cuenta, Container y blob.

Todas las cuentas se crean con el sufijo *.core.windows.net, en ese asterisco caben los tipos de almacenamiento que permiten crear las Storage Accounts: blob, table, queue o file. Es por eso que el nombre de cuenta debe ser unívoco, y no puede haber dos cuentas con el mismo nombre.

Con esto en mente, entramos en lo que son los SAS: una Shared Access Signature o SAS es, a primera vista, un Link. Pero es un link que apunta a un recurso del almacenamiento en Cloud concreto, a un nivel determinado (cuenta, contenedor o blob), con unos permisos específicos (lectura, escritura, listado, creación, borrado…) e incluso con un periodo de validez (entre X y X fecha).

La forma de otorgar estos permisos tan específicos es a través de un código que viene en el propio link. Es la forma de “validar” el acceso concedido a la gente a la que entreguemos este SAS. Veamos un SAS como ejemplo para un blob, un archivo en particular

https://storagevideotutorial.blob.core.windows.net/documentos/test txt.txt?sp=r&st=2018-05-30T07:38:46Z&se=2018-05-30T15:38:46Z&spr=https&sv=2017-11-09&sig=gqhtPRXVspX5qjYCDSsg4EPk7BwctyWbm3CieQwxhhY%3D&sr=b 

Desguacemos este link por piezas.

https://storagevideotutorial.blob.core.windows.net/documentos/test txt.txt 

Es la parte que apunta al recurso. Un txt llamado “test txt”, en un container llamado documentos dentro de una cuenta llamada “storagevideotutorial”, con su sufijo blob.core.windows.net.

Por la forma de la URL, tiene pinta de pasar el resto de SAS como valores por PHP, sobre todo por ver ese “?” al principio de la siguiente sección y el “&” para enlazar variables dentro del link.

sp=r&st=2018-05-30T07:38:46Z&se=2018-05-30T15:38:46Z&spr=https&sv=2017-11-09 

Es la sección que especifica las fechas de validez, y el acceso (por https), e incluso un valor SV que tiene una fecha de 2017, puede ser la versión del servicio.

sig=gqhtPRXVspX5qjYCDSsg4EPk7BwctyWbm3CieQwxhhY%3D&sr=b 

Es la parte que aporta la clave para validarme. Obviamente, la clave determina el nivel de acceso al recurso concreto, de forma que, aunque yo tenga la “picardía” de modificar a posteriori los valores del link (para darme otras fechas de validez, por ejemplo, o para darme acceso a otro recurso dentro del container, o a toda la cuenta de almacenamiento), no me iba a valer, y en buena lógica, viendo el formato del valor SIG (de signature: Firma) no puedo “modificarlo” para darme más permisos sobre el recurso al que apunta.

Tanto haciendo clic derecho sobre el blob (el archivo txt de prueba) como yendo a la sección “shared Access signature” en la cuenta de almacenamiento, podemos “tunear” el nivel de acceso y las fechas de validez de nuestra SAS, pero ¿Y a nivel Container? Porque lo óptimo sería tener varios Containers en una misma cuenta (no cientos de cuentas con un container cada una para gestionar el acceso de forma granular), y distribuir el acceso a distintos usuarios a través de SAS. Sin embargo, Azure no da opción a sacar un SAS de un container específico, como mucho, nos permite habilitar el acceso anónimo a los archivos (si tenemos el enlace al blob) o a todo el container (navegar por él como si fuera lo más parecido a una carpeta compartida), pero nada de crear un SAS. ¿Y si tenemos un container que no queremos que se vea? Otorgar permisos a cada blob dentro del container es farragoso, y otorgar permisos a toda la cuenta sería dar más permisos de los que quiero…

¿Cómo resolveremos esta situación? La respuesta la tenemos en Azure Storage Explorer. Herramienta gratuita que nos permite gestionar SAS a nivel de contenedor, y otras ventajas tales como poder conectarnos a los recursos usando nuestros SAS, ya que, a pesar del formato URL, poner la SAS directamente en el browser muchas veces da problemas:

Esta es una respuesta muy común al meter una SAS a un recurso que el browser no puede interpretar. Tal vez con un TXT o una imagen no pase, pero no nos vamos a limitar sólo a esos tipos de archivo en nuestro almacenamiento.

En este videotutorial se muestra cómo obtener una SAS para un container específico con permisos restringidos a través de Azure Storage Explorer, contado desde la creación de la cuenta de almacenamiento. Espero que os sea de utilidad.

Autor: Gabriel Piuzzi

Curso: Microsoft MCSA Windows Server + Microsoft MCSE Cloud Platform & Infrastructure

Centro: Tajamar

Año académico: 2017-2018

Leave a Comment

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *