Azure Blob Storage: acceso público y SAS paso a paso

Azure Blob Storage es el servicio de almacenamiento de objetos de Microsoft Azure, diseñado para guardar datos no estructurados como imágenes, videos, backups y archivos de log a escala masiva. En mayo de 2026, sigue siendo la opción de referencia para proyectos cloud que necesitan storage accesible vía HTTP con control granular de permisos.

Microsoft es una corporación estadounidense de tecnología fundada en 1975 que desarrolla software, sistemas operativos y servicios en la nube. Proporciona productos y soluciones digitales para empresas y usuarios, incluyendo Windows, Office y Azure.

Crear una Cuenta Azure Storage

El punto de partida de todo es la Storage Account. Según la documentación oficial de Microsoft, esta cuenta es el namespace único que agrupa todos tus servicios de almacenamiento: Blobs, Files, Queues y Tables.

Para crear una, entrás al Portal de Azure, buscás “Storage accounts” y hacés clic en “Create”. Los campos que importan de verdad:

• Resource Group: un contenedor lógico para agrupar recursos relacionados. Si después querés borrar todo el proyecto, borrás el grupo y listo.
• Storage Account Name: tiene que ser único a nivel global entre todos los clientes de Azure, solo minúsculas y números, entre 3 y 24 caracteres. En el ejemplo de la guía de dev.to, usaron prodjemegastorage1.
• Region: elegí la más cercana a tus usuarios finales. El ejemplo usa Africa (South Africa North) porque el proyecto estaba en esa zona geográfica. En Latinoamérica vas a optar por Brazil South o alguna de las regiones US.
• Performance: Standard para la mayoría de casos, Premium solo si necesitás latencia muy baja (por ejemplo, discos de VMs).
• Redundancy: LRS (Locally Redundant Storage) replica los datos 3 veces dentro del mismo datacenter. GRS (Geo-Redundant) los replica en una región secundaria. LRS es lo más barato, GRS es lo que usás si el downtime te cuesta caro.

Al crear la cuenta también activás “Allow Blob Public Access” si querés después habilitar acceso anónimo a contenedores específicos. Ojo: esto es un interruptor a nivel de cuenta que necesitás prender antes de poder configurarlo a nivel de contenedor.

Qué es Azure Blob Storage y para qué sirve

Blob Storage es el servicio de objetos dentro de la cuenta de storage. “Blob” viene de Binary Large Object, que es básicamente cualquier archivo que no tenga esquema fijo: imágenes, videos, PDFs, backups de base de datos, logs, datasets para machine learning.

Hay tres tipos de blobs según la introducción oficial:

• Block blobs: el tipo estándar para la mayoría de archivos. Se suben en bloques paralelos, lo que los hace eficientes para archivos grandes.
• Append blobs: optimizados para operaciones de append, ideal para logs que se escriben de forma continua.
• Page blobs: para lectura/escritura aleatoria, los usan los discos de VMs de Azure internamente.

Para el 90% de los casos, vas a usar block blobs. Los otros dos tipos tienen casos de uso muy específicos.

Crear un Contenedor y Subir Archivos

Dentro de la Storage Account, los blobs se organizan en contenedores (equivalentes a buckets en S3). Para crear uno, vas a “Containers” en el menú lateral y hacés clic en “+ Container”.

El nombre del contenedor acepta minúsculas, números y guiones. Lo más importante acá es el nivel de acceso público. Esto se conecta con lo que analizamos en integración entre servicios de Microsoft.

Nivel de acceso	Qué permite	Cuándo usarlo
Private (sin acceso público)	Solo acceso autenticado	Datos sensibles, backups, documentos internos
Blob	Lectura anónima de blobs individuales (si conocés la URL)	Assets públicos con URL directa
Container	Lectura anónima de blobs Y listado del contenedor	Casi nunca — expone todos tus archivos

Para subir archivos desde el Portal, entrás al contenedor y usás el botón “Upload”. Para automatizar o subir volumen, las opciones son:

• AzCopy: herramienta de línea de comandos, ideal para migraciones masivas
• Azure Storage Explorer: cliente de escritorio con interfaz gráfica
• SDK de .NET, Python, JavaScript: para integración desde código
• Azure CLI: az storage blob upload directo desde terminal

Habilitar Acceso Público al Contenedor

Si configuraste el nivel “Blob” en el contenedor, cualquier persona con la URL del archivo puede accederlo sin autenticación. La URL tiene este formato:

https://[cuenta].blob.core.windows.net/[contenedor]/[archivo]

Cuándo tiene sentido: assets de un sitio web (imágenes, CSS, JS), archivos de descarga pública, datasets abiertos. Cuándo NO: datos de usuarios, configuraciones, backups con información sensible, cualquier cosa que no quieras indexada por bots.

El acceso público es permanente mientras esté activo (no expira). Si necesitás acceso temporal o controlado, usás SAS.

Generar y Configurar Shared Access Signature (SAS)

Un Shared Access Signature es una URL firmada que da acceso delegado a recursos de storage con permisos y tiempo de expiración específicos. Según Microsoft, hay tres tipos:

• User Delegation SAS: firmado con credenciales de Azure AD. El más seguro, recomendado para producción.
• Service SAS: firmado con la clave de la cuenta, acceso a un solo servicio (Blob, Queue, etc.)
• Account SAS: firmado con la clave de la cuenta, acceso a múltiples servicios.

Para generar un SAS desde el Portal: seleccionás el blob, hacés clic derecho y elegís “Generate SAS”. Ahí configurás:

• Signing method: Account key o User delegation key
• Permissions: Read, Write, Delete, List, Add, Create (marcá solo los que necesitás)
• Start and expiry date/time: ponele hora de inicio unos minutos antes de la actual para evitar problemas de sincronización de relojes entre servidores
• Allowed protocols: HTTPS only (nunca HTTP solo)
• Allowed IP addresses: podés restringir a una IP o rango específico

La URL resultante se ve así: https://[cuenta].blob.core.windows.net/[contenedor]/[blob]?sv=2023-08-03&st=...&se=...&sr=b&sp=r&sig=...

¿Y qué significan esos parámetros? El se es la expiración, sp son los permisos (r = read), sig es la firma criptográfica. Si alguien modifica cualquiera de estos valores, la firma no coincide y el acceso se rechaza. Lo explicamos a fondo en automatizar la subida de archivos en tus pipelines.

Seguridad: Lo que Tenés que Saber Antes de Salir a Producción

Ponele que generaste un SAS y lo mandás a un cliente para que descargue un informe. El cliente lo guarda en un Slack interno, alguien copia la URL, y de repente tenés 50 personas distintas descargando ese archivo. (sí, en serio, pasa seguido).

Las mejores prácticas según la documentación oficial:

• HTTPS siempre: configurá el parámetro de protocolo a HTTPS only. Un SAS sobre HTTP expone la firma en texto plano y puede ser interceptada.
• Duración mínima necesaria: Microsoft tiene un límite de 48 horas para User Delegation SAS con la configuración estándar. Para acceso puntual, usá horas, no días.
• User Delegation SAS sobre Account SAS: la clave de cuenta tiene acceso total a toda la storage account. Si alguien la obtiene, la rotás y todos los SAS basados en ella expiran. Con User Delegation, usás Azure AD y podés revocar sin afectar a los demás.
• Restringí por IP cuando puedas: si sabés de qué IP se va a acceder, limitalo.
• No hardcodees SAS en código fuente: usá Azure Key Vault o variables de entorno.

Oración larga que resume el flujo mental correcto: creás la Storage Account con los parámetros básicos, configurás el contenedor con el nivel de acceso más restrictivo posible para tu caso de uso, generás los SAS con tiempo de expiración ajustado a lo que realmente necesitás, los almacenás en un lugar seguro como Key Vault, y cuando algo falla revisás primero los logs de diagnóstico antes de empezar a cambiar permisos al azar.

Solución de Problemas: Errores 403 y Otros Clásicos

El error 403 en Azure Blob Storage tiene varios orígenes posibles. Según la guía de troubleshooting de Microsoft, los más comunes son:

SAS expirado: el más obvio pero el más fácil de olvidar. Revisá el parámetro se en la URL y compará con la hora actual UTC (no tu hora local).

Protocolo incorrecto: si generaste el SAS con “HTTPS only” y alguien accede via HTTP, falla con 403. No con un error descriptivo, con un 403 genérico.

Tipo de recurso mal configurado (srt en Account SAS): el parámetro srt define a qué nivel se aplica el SAS (s=service, c=container, o=object). Si falta o y estás intentando acceder a un blob específico, se rechaza.

Desfase de tiempo entre el inicio del SAS y el acceso: si configuraste el inicio del SAS para “ahora” pero hay una diferencia de reloj entre el servidor que generó el SAS y el que lo valida, podés caer en un período donde el SAS todavía no es válido. La solución es poner el inicio 5-15 minutos antes de la hora actual.

Acceso público deshabilitado a nivel de cuenta: si el switch de “Allow Blob Public Access” está en Off a nivel de Storage Account, ningún contenedor puede tener acceso público, aunque lo hayas configurado a nivel de contenedor. Relacionado: orquestar deployments a blob storage.

La forma más rápida de diagnosticar: en el Portal, buscás la Storage Account, entrás a “Monitoring > Diagnostics settings”, habilitás los logs de storage y revisás las entradas con status 403. Ahí vas a ver el motivo exacto.

Errores Comunes que Comete Casi Todo el Mundo

1. Nombre de Storage Account con mayúsculas o caracteres especiales: Azure rechaza el nombre en el momento de creación, pero si venís de AWS donde los buckets aceptan guiones y mayúsculas, el cambio de mentalidad tarda. Solo minúsculas y números.

2. Generar SAS a nivel de contenedor cuando necesitás acceso a un blob específico: un SAS de tipo “Container” (sr=c) y uno de tipo “Blob” (sr=b) tienen URLs distintas. Si usás el del contenedor para acceder a un blob sin la ruta correcta, falla.

3. Usar acceso público en vez de SAS para “simplificar”: el acceso público no tiene expiración, no se puede revocar por blob individual, y si habilitás “Container” level (no “Blob”), exponés el listado completo del contenedor. Para archivos que querés compartir por tiempo limitado, SAS siempre.

4. Olvidar que las claves de cuenta rotan: Azure genera dos claves por Storage Account. Si rotás la clave 1 (lo que Microsoft recomienda hacer periódicamente), todos los Service SAS y Account SAS firmados con esa clave dejan de funcionar. Si estás usando User Delegation SAS, esto no te afecta.

5. No configurar CORS cuando los blobs se acceden desde el browser: si tenés una app web que accede directamente a blobs vía JavaScript, necesitás configurar CORS en la Storage Account. Sin eso, el browser bloquea las requests aunque el SAS sea válido.

Si tu proyecto cloud está en Argentina y necesitás storage confiable para assets web o archivos de clientes, donweb.com tiene opciones de hosting y cloud pensadas para el mercado local, con soporte en español.

Preguntas Frecuentes

¿Cómo crear una cuenta de almacenamiento en Azure desde cero?

Desde el Portal de Azure, buscás “Storage accounts” y usás el botón “+ Create”. Completás el grupo de recursos, el nombre único global (solo minúsculas y números, 3-24 caracteres), la región más cercana a tus usuarios, el tipo de performance (Standard para la mayoría de casos) y la redundancia (LRS es la opción base). El proceso toma menos de 5 minutos. Cubrimos ese tema en detalle en servir contenido en múltiples idiomas.

¿Cuál es la diferencia entre acceso público y SAS en Azure Blob Storage?

El acceso público es permanente y no requiere autenticación: cualquiera con la URL puede leer el archivo mientras el contenedor tenga ese nivel configurado. Un SAS (Shared Access Signature) es una URL firmada con expiración, permisos específicos y opcionalmente restricción por IP. Para compartir archivos con tiempo límite o con control de quién accede, SAS es la opción correcta.

¿Cómo generar un token SAS seguro en Azure?

En el Portal, seleccionás el blob o contenedor, usás la opción “Generate SAS”, configurás los permisos mínimos necesarios, ponés el tiempo de inicio 5-15 minutos antes de la hora actual (para evitar desfases de reloj), establecés la expiración en el menor tiempo posible para tu caso, y seleccionás “HTTPS only” en protocolos permitidos. Para producción, usá User Delegation SAS en vez de Account key.

¿Por qué aparece error 403 al acceder a un blob con SAS?

Los motivos más frecuentes son: SAS expirado (revisá el parámetro se en UTC), protocolo HTTP cuando el SAS requiere HTTPS, tipo de recurso incorrecto en el parámetro sr (container vs blob), acceso público deshabilitado a nivel de Storage Account, o desfase de reloj entre la hora de generación y la de acceso. Los logs de diagnóstico en Azure Portal muestran el motivo exacto del rechazo.

¿Cuánto cuesta Azure Blob Storage?

El costo depende de la región, el tier de acceso y el volumen. En el tier Hot (acceso frecuente), el almacenamiento en regiones de Estados Unidos cuesta alrededor de USD 0.018 por GB/mes, más el costo de operaciones de lectura/escritura. El tier Cool (acceso infrecuente) baja el costo de almacenamiento pero sube el de acceso. Para archivos que raramente se leen, el tier Archive baja el costo a menos de USD 0.002 por GB/mes, pero el tiempo de rehidratación puede ser de horas.

Conclusión

Azure Blob Storage tiene una curva de aprendizaje corta para lo básico: crear la cuenta, subir archivos y generar un SAS se hace en menos de 30 minutos siguiendo los pasos del Portal. Lo que sí lleva tiempo entender bien es la diferencia entre los tipos de SAS, cuándo usar acceso público versus token firmado, y cómo diagnosticar errores 403 que no siempre son obvios.

El consejo más práctico: si estás arrancando un proyecto nuevo y no sabés si los archivos van a ser públicos o privados, configurá todo como privado desde el inicio. Agregar acceso público después es trivial; revocar acceso que ya está expuesto es más complicado (y en el peor caso, imposible si la URL ya se distribuyó).

Para equipos que trabajan en producción, el salto de Account SAS a User Delegation SAS vale el esfuerzo de configurar Azure AD. No porque sea obligatorio, sino porque te da la posibilidad de revocar acceso sin rotar las claves de la cuenta y sin afectar otros servicios. Es una de esas decisiones de arquitectura que se agradecen cuando algo sale mal.

Fuentes

• Dev.to — Guía paso a paso de Azure Blob Storage con ejemplos reales
• Microsoft Learn — Introducción a Azure Blob Storage
• Microsoft Learn — Descripción general de Shared Access Signatures (SAS)
• Microsoft Learn — Solución de problemas 403 en Azure Storage
• Microsoft Learn — Inicio rápido de Blob Storage desde el Portal