En el dominio de almacenamiento de AZ-104 (15–20 %), el primer bloque del temario oficial es "configurar el acceso al almacenamiento". Ahí están los firewalls y redes virtuales, los tokens SAS, las directivas de acceso almacenadas, las claves de acceso y el acceso basado en identidades para Azure Files, y en nuestro banco de preguntas las preguntas sobre firewalls y permisos de acceso suponen casi la mitad de las de almacenamiento. Lo complicado es que estas funciones actúan en capas distintas. Si abres el firewall sin los permisos adecuados recibes un 403; si tienes los permisos pero el firewall te bloquea, tampoco entras.
Este artículo separa los dos filtros que debe pasar toda solicitud de almacenamiento: la red y la autorización. Veremos la configuración de acceso de red pública y las reglas de firewall, los cuatro métodos de autorización, los tres tipos de SAS y las directivas de acceso almacenadas, la rotación de claves de acceso y la desactivación de Shared Key, el acceso basado en identidades para Azure Files y el cifrado en reposo. Lo básico, como redundancia, niveles de acceso y administración del ciclo de vida, está en Guía Completa de Administración de Almacenamiento.
---
Dos Filtros que Debe Pasar Toda Solicitud de Almacenamiento
Para entrar en un edificio de oficinas primero pasas por el control de seguridad de la entrada principal y luego pasas tu tarjeta en la puerta de la oficina. Superar la recepción no significa que puedas entrar en cualquier oficina, y tener tarjeta no sirve de nada si la entrada principal está cerrada. Azure Storage revisa cada solicitud dos veces de la misma manera.
| Filtro | Qué comprueba | Dónde se configura | |------|------|------| | 1. Red | De dónde viene la solicitud (internet, una VNet concreta, una IP concreta, un punto de conexión privado) | Cuenta de almacenamiento → Redes | | 2. Autorización | Si quien llama puede hacer esta operación (clave, SAS, Entra ID, anónimo) | Claves de acceso, SAS, Control de acceso (IAM), nivel de acceso del contenedor |
!Una solicitud de almacenamiento debe pasar el filtro de red y el filtro de autorización
Consejo para el examen: Si "el token SAS es válido, pero el acceso se deniega solo desde una oficina", sospecha del filtro de red (reglas de firewall), no de la autorización. Si "se agregó una regla de VNet, pero las solicitudes fallan con un error 403 de permisos", revisa el rol de datos de RBAC o los permisos del SAS.
---
El Filtro de Red: Acceso de Red Pública y Reglas de Firewall
La primera decisión en la página Redes de una cuenta de almacenamiento es el nivel de acceso de red pública.
| Configuración | Comportamiento | |------|------| | Habilitado desde todas las redes | Accesible desde cualquier lugar de internet (solo queda el filtro de autorización) | | Habilitado desde redes virtuales y direcciones IP seleccionadas | Solo se permiten las solicitudes que cumplen las reglas de abajo; el resto se bloquea | | Deshabilitado | El punto de conexión público se bloquea; acceso solo a través de puntos de conexión privados |
Cuando eliges redes seleccionadas, combinas reglas de permiso.
| Regla | Qué permite | Qué recordar | |------|------|------| | Regla de red virtual | Una subred concreta de una VNet concreta | La subred necesita el punto de conexión de servicio Microsoft.Storage (el portal lo crea automáticamente) | | Regla de red IP | Direcciones o intervalos de IP públicas | No se permiten IP privadas (10.x, 172.16–31.x, 192.168.x); los /31 y /32 se escriben como IP individuales | | Regla de instancia de recurso | Una instancia concreta de un recurso de Azure | Recursos del mismo inquilino; lo que pueden hacer lo deciden las asignaciones de roles de ese recurso | | Excepción de servicios de confianza | Servicios de Azure de la lista de confianza | Para servicios que no se pueden aislar por VNet ni por IP |
Las reglas de IP esconden una trampa muy preguntada. Las reglas de red IP no tienen efecto sobre las solicitudes que vienen de la misma región de Azure que la cuenta de almacenamiento, porque los servicios de la misma región se comunican con direcciones IP privadas de Azure. Para permitir o restringir el acceso desde VM de la misma región hay que usar reglas de red virtual. Además, en cuanto habilitas un punto de conexión de servicio en una subred, el tráfico de esa subred usa una IP privada como origen, así que las reglas de IP que permitían la IP pública de esa subred dejan de aplicarse.
Un punto de conexión privado da a la cuenta de almacenamiento una IP privada dentro de tu VNet, de modo que, aunque el acceso de red pública esté Deshabilitado, el tráfico que llega por el punto de conexión privado sigue pasando. Los puntos de conexión de servicio y los privados se comparan con un diagrama en VNet, NSG, DNS y Load Balancer Explicados para Principiantes.
Consejo para el examen: "Permitir el acceso solo desde la IP pública 203.0.113.10 de la oficina local" es una regla de red IP. "Permitir solo Subnet1 de VNet1 en la misma región" es una regla de red virtual más un punto de conexión de servicio. "Bloquear internet por completo y permitir el acceso solo por una IP privada de la VNet" es un punto de conexión privado con el acceso de red pública deshabilitado.
---
El Filtro de Autorización: Cuatro Formas de Demostrar el Acceso
Una solicitud que pasa el filtro de red demuestra sus derechos de una de estas cuatro formas.
| Método | Prueba | Características | |------|------|------| | Microsoft Entra ID | Token de un usuario, grupo o identidad administrada + un rol de datos de RBAC | Recomendado por Microsoft, admite acceso condicional y auditoría | | Shared Key | Clave de acceso de la cuenta | Una sola clave da todos los derechos sobre todos los datos de la cuenta | | SAS | Token de URL firmado | Delegación limitada por tiempo, permisos y destino | | Lectura anónima | Ninguna | Solo funciona si se permite en la cuenta y después se activa en el nivel del contenedor |
Microsoft recomienda Entra ID e identidades administradas de forma predeterminada, y claves solo cuando de verdad hagan falta. Para leer y escribir blobs con Entra ID se necesita un rol de datos como Storage Blob Data Reader o Storage Blob Data Contributor, como se explica en Cómo Interpretar Asignaciones de Roles de Azure RBAC en AZ-104.
---
Tres Tipos de SAS y Directivas de Acceso Almacenadas
Una SAS (firma de acceso compartido) funciona como la tarjeta de una habitación de hotel. La recepción emite una tarjeta que abre una habitación concreta hasta una fecha concreta. Lo que cambia es con qué se firmó la tarjeta, y eso da tres tipos.
| Tipo | Firmada con | Destino | Directiva de acceso almacenada | Si se desactiva Shared Key | |------|------|------|------|------| | SAS de delegación de usuarios | Una clave de delegación de usuarios obtenida con credenciales de Entra | Blob (incluido Data Lake), colas, tablas, Azure Files | No compatible | Sigue funcionando | | SAS de servicio | Clave de acceso de la cuenta | Un solo servicio de almacenamiento | Compatible | Se deniega | | SAS de cuenta | Clave de acceso de la cuenta | Uno o varios servicios, incluidas operaciones de nivel de servicio | No compatible | Se deniega |
Cuando necesitas una SAS, Microsoft recomienda la SAS de delegación de usuarios, porque la protegen credenciales de Entra en lugar de la clave de la cuenta. Una clave de delegación de usuarios es válida como máximo siete días, así que una SAS de delegación de usuarios tampoco puede caducar más allá de siete días.
Directivas de Acceso Almacenadas
Una directiva de acceso almacenada es una "regla de emisión de tarjetas" que defines de antemano en un contenedor, cola, tabla o recurso compartido de archivos. Cuando una SAS de servicio hace referencia a la directiva, hereda de ella la hora de inicio, la hora de expiración y los permisos.
Hasta cinco por contenedor (o cola, tabla o recurso compartido) Crear o cambiar una directiva puede tardar hasta 30 segundos en aplicarse Eliminar la directiva, cambiar su identificador o poner su expiración en el pasado invalida todas las SAS vinculadas Solo funciona con SAS de servicio; las SAS de delegación de usuarios y de cuenta solo pueden ser ad hoc
Formas de Invalidar una SAS Ya Emitida
| Método | Alcance del impacto | |------|------| | Esperar a que caduque | Solo esa SAS (una expiración corta es el valor predeterminado más seguro) | | Eliminar o cambiar la directiva de acceso almacenada | Todas las SAS de servicio que hacen referencia a la directiva | | Volver a generar la clave de cuenta usada para firmar | Todas las SAS de servicio y de cuenta firmadas con esa clave + todas las aplicaciones que usan esa clave | | Revocar las claves de delegación de usuarios | Todas las SAS de delegación de usuarios de la cuenta |
Consejo para el examen: Para poder "invalidar de inmediato un grupo de tokens SAS emitidos sin afectar a otras SAS ni aplicaciones", hay que emitirlos desde el principio como SAS de servicio vinculadas a una directiva de acceso almacenada. Volver a generar la clave tiene el mayor alcance y suele aparecer como respuesta incorrecta.
---
Administrar las Claves de Acceso y Desactivar Shared Key
Toda cuenta de almacenamiento nueva recibe dos claves de acceso de 512 bits. Son dos para poder rotarlas sin interrumpir las aplicaciones.
Si las aplicaciones usan key1, primero cambia su configuración a key2 Vuelve a generar key1 Cambia las aplicaciones a la nueva key1 y después vuelve a generar key2
Microsoft recomienda guardar las claves en Azure Key Vault y rotarlas con regularidad. Como una clave de acceso da todos los derechos sobre todos los datos de la cuenta y la capacidad de emitir tokens SAS, también hay que controlar a quién se dan roles que pueden leer las claves (Owner, Contributor, Storage Account Contributor, etc.).
Yendo un paso más allá, si desactivas "Permitir el acceso de clave de cuenta de almacenamiento" (AllowSharedKeyA