AZ-104
Deep Dive
El acceso seguro a Azure Storage es uno de los temas más examinados del AZ-104. Necesitas dominar los 4 métodos de autorización, los 3 tipos de SAS, el storage firewall y cuándo usar Private Endpoints.
Contenido
Azure Storage soporta 4 métodos de autorización distintos. El AZ-104 evalúa cuándo usar cada uno y cuál es más seguro para cada escenario.
| Método | Quién lo usa | Granularidad | Riesgo |
|---|---|---|---|
| Access Keys (Shared Key) | Aplicaciones, scripts, CLI | Acceso TOTAL a la cuenta | 🔴 Alto — equivale a root |
| SAS (Shared Access Signature) | Clientes externos, apps de terceros | Por servicio/contenedor/blob + permisos + tiempo | 🟡 Medio — limitado por diseño |
| Azure AD (Entra ID) + RBAC | Usuarios, servicios, Managed Identities | Por roles (Storage Blob Data Reader, etc.) | 🟢 Bajo — gestión centralizada |
| Anonymous (Public Access) | Cualquier usuario de internet | Solo lectura, solo contenedores públicos | 🔴 Alto — sin autenticación |
Microsoft recomienda: Entra ID + RBAC siempre que sea posible
Entra ID elimina la necesidad de gestionar secretos (keys, SAS tokens). Con Managed Identities, la aplicación no almacena ninguna credencial. Microsoft ha declarado que el objetivo es deprecar el uso de Shared Key en el futuro.
Cada Storage Account tiene 2 access keys (key1 y key2). Son equivalentes — tener una es tener acceso total. Se usan principalmente en escenarios donde Entra ID no está disponible.
Riesgos de Access Keys
Rotación de keys — zero downtime
El patrón de 2 keys permite rotar sin downtime:
1. App usa key1 actualmente
2. Actualizar app para usar key2
3. Regenerar key1 (ya no la usa nadie)
4. Si necesitas rotar de nuevo → volver a key1
Azure Key Vault puede gestionar la rotación automática de storage keys.
Un SAS token es un URI con parámetros firmados que concede acceso temporal y limitado a recursos de Storage. Es la forma de dar acceso a clientes externos sin exponer las access keys.
| Tipo de SAS | Firmado con | Alcance | Revocación |
|---|---|---|---|
| Account SAS | Access Key de la cuenta | Uno o más servicios (Blob, File, Queue, Table) de la cuenta entera | Regenerar la access key (afecta todos los SAS firmados con esa key) |
| Service SAS | Access Key de la cuenta | Un servicio especÃfico: un contenedor, un blob, un file share, etc. | Regenerar la access key (misma limitación) |
| User Delegation SAS | Credenciales de Entra ID del usuario | Solo Blob y Queue. Máximo 7 dÃas de validez. | Revocar las credenciales del usuario en Entra ID (granular) |
Parámetros de un SAS token
sv=2021-06-08 // Storage service version
ss=b // Service: b=blob, f=file, q=queue, t=table
srt=co // Resource types: s=service, c=container, o=object
sp=rwdlacup // Permissions: r=read, w=write, d=delete, l=list, a=add, c=create, u=update, p=process
se=2024-12-31T23:59:59Z // Expiry time (UTC)
sip=192.168.1.0/24 // Allowed IPs (opcional)
spr=https // Protocol: https or https,http
sig=base64EncodedSignature // HMAC-SHA256 signature
Stored Access Policy — control adicional
Una Stored Access Policy (SAP) vincula un SAS a una polÃtica definida en el contenedor. Permite revocar un SAS sin regenerar la access key: solo modifica o elimina la SAP. Máximo 5 SAPs por contenedor. Recomendado para SAS de larga duración.
Azure Storage soporta autenticación via Entra ID para Blob, Queue y Table (no File nativo). Los roles de RBAC de datos de storage son distintos de los roles de gestión.
| Rol de Storage Data | Permisos | Scope tÃpico |
|---|---|---|
| Storage Blob Data Owner | CRUD completo + cambiar ACLs (ADLS Gen2) | Cuenta o contenedor |
| Storage Blob Data Contributor | Leer, escribir, eliminar blobs y contenedores | Cuenta o contenedor |
| Storage Blob Data Reader | Solo lectura de blobs y metadatos de contenedores | Cuenta o contenedor |
| Storage Blob Delegator | Puede generar User Delegation SAS tokens | Cuenta únicamente |
| Storage Queue Data Contributor | CRUD en mensajes de Queue | Cuenta o cola |
| Storage Table Data Contributor | CRUD en entidades de Table Storage | Cuenta o tabla |
| Storage File Data SMB Share Contributor | Lectura/escritura/eliminación en Azure Files via SMB con Entra Kerberos | File share |
Contributor ≠Storage Blob Data Contributor
El rol Contributor (de gestión de Azure) permite gestionar la Storage Account pero NO puede leer el contenido de los blobs. Se necesita un rol de datos (Storage Blob Data *) para acceder a los datos.
El Storage Firewall controla desde dónde se puede acceder a la Storage Account. Por defecto todas las redes están permitidas. Al habilitar el firewall, solo las reglas permitidas pueden acceder.
Tipos de reglas de red
IP Rules
Permite direcciones IP públicas especÃficas o rangos CIDR. No soporta IPs privadas (RFC 1918) — para eso usar VNet rules.
VNet Rules (Service Endpoints)
Permite tráfico desde subnets especÃficas de VNets. Requiere habilitar el Service Endpoint Microsoft.Storage en la subnet.
Resource Instances
Permite acceso a servicios Azure especÃficos (ej: Azure Backup, Azure Site Recovery) aunque el firewall esté activo.
Trusted Microsoft Services
Excepción que permite servicios de confianza de Microsoft (Azure Monitor, Backup, Azure AD, etc.) saltarse el firewall.
Service Endpoints vs Private Endpoints
Service Endpoint
Private Endpoint
Un Private Endpoint crea una NIC con IP privada en tu VNet que representa un servicio de Azure. El tráfico hacia la Storage Account nunca sale a internet.
Subrecursos de Storage para Private Endpoints
| Subrecurso | Servicio | DNS Zone |
|---|---|---|
| blob | Blob Storage | privatelink.blob.core.windows.net |
| file | Azure Files (SMB/NFS) | privatelink.file.core.windows.net |
| queue | Queue Storage | privatelink.queue.core.windows.net |
| table | Table Storage | privatelink.table.core.windows.net |
| dfs | ADLS Gen2 (Data Lake) | privatelink.dfs.core.windows.net |
| web | Static Website | privatelink.web.core.windows.net |
DNS es crÃtico con Private Endpoints
Con Private Endpoint, el nombre DNS de la storage (mystorageaccount.blob.core.windows.net) debe resolverse a la IP privada, no a la pública. Se usa una Private DNS Zone vinculada a la VNet. Sin esto, los clientes resolverán la IP pública y el firewall bloqueará la conexión.
Cifrado en reposo (Storage Service Encryption)
Cifrado en tránsito
| Tipo de clave | Gestionada por | Rotación | Cuándo usar |
|---|---|---|---|
| Microsoft Managed Keys (MMK) | Microsoft | Automática | MayorÃa de casos — sin overhead operativo |
| Customer Managed Keys (CMK) | Cliente (en Azure Key Vault) | Manual o automática (Key Vault) | Compliance que requiere control de claves (PCI-DSS, HIPAA) |
| Customer Provided Keys (CPK) | Cliente (en cada request) | Cliente decide | Casos muy especiales — sin Key Vault integrado |
User Delegation SAS es el más seguro — firmado con Entra ID
El User Delegation SAS se firma con credenciales de Entra ID (no con la access key). Puede revocarse granularmente quitando el permiso al usuario en Entra, sin afectar a otros SAS. Máximo 7 dÃas de validez para Blob/Queue. Es la opción más segura entre los tipos de SAS.
Contributor no puede leer datos de Blob
El rol Contributor da acceso de gestión a la Storage Account (crear, configurar, eliminar) pero NO da acceso al contenido de los blobs o colas. Para leer datos necesitas Storage Blob Data Reader o Storage Blob Data Contributor.
Service Endpoints no crean IPs privadas
Service Endpoints restringen el tráfico para que salga solo desde subnets autorizadas, pero la storage sigue teniendo IP pública. Private Endpoints sà crean una IP privada en la VNet. Para escenarios donde el tráfico NO puede salir a internet, la respuesta es Private Endpoint.
Revocar un SAS firmado con Access Key requiere regenerar la key
No existe forma de revocar un SAS de Account o Service SAS individualmente (a menos que use Stored Access Policy). La única forma es regenerar la Access Key — lo que invalida TODOS los SAS firmados con esa key. User Delegation SAS sà puede revocarse quitando el permiso al usuario.
Anonymous access deshabilitado a nivel cuenta deshabilita todos los contenedores
Azure 2023+: hay una configuración a nivel Storage Account "Allow Blob anonymous access". Si está deshabilitado, TODOS los contenedores son privados aunque individualmente tengan public access configurado. La configuración de cuenta anula la del contenedor.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una aplicación web en Azure App Service necesita leer blobs de una Storage Account. La polÃtica de seguridad prohÃbe almacenar secretos o access keys en el código o configuración de la app. ¿Cuál es la solución correcta?