Protección de la cuenta de Azure Storage

Azure Storage ofrece almacenamiento en la nube escalable y duradero para blobs, archivos, colas y tablas en una sola cuenta de almacenamiento. Dado que una cuenta de almacenamiento puede contener datos de niveles de sensibilidad muy diferentes y suele ser objetivo de ataques de exfiltración y ransomware, toma medidas deliberadas para proteger la cuenta, los datos que contiene y las identidades que acceden a ella.

Este artículo ofrece recomendaciones de seguridad para ayudar a proteger tu cuenta de Azure Storage. Estas recomendaciones se aplican a todos los servicios de datos de la cuenta (Blobs, Files, Queues y Tables). Para orientación específica para cada servicio de datos, consulte los artículos relacionados sobre seguridad al final de este artículo.

Las recomendaciones de seguridad de este artículo implementan principios de confianza cero: "Comprobar explícitamente", "Usar acceso con privilegios mínimos" y "Asumir vulneración de seguridad". Para obtener instrucciones de Confianza cero completas, consulte el Centro de instrucciones Confianza cero.

Seguridad específica del servicio

Azure Storage tiene características arquitectónicas que moldean cómo lo despliegas de forma segura. Las decisiones que tomas al crear una cuenta —modelo de despliegue, tipo, redundancia y configuración del endpoint— son difíciles de cambiar después y afectan a la postura de seguridad de cada carga de trabajo que utiliza la cuenta.

Arquitectura de cuentas de almacenamiento

  • Utiliza el modelo de despliegue de Azure Resource Manager: Crea nuevas cuentas de almacenamiento utilizando el modelo de despliegue de Azure Resource Manager. Las cuentas de Resource Manager soportan control de acceso basado en roles (RBAC) de Azure, identidades gestionadas, autorización Microsoft Entra ID para datos, bloqueos de recursos, etiquetas y políticas, ninguno de los cuales está disponible con el modelo clásico de despliegue. Migra cualquier cuenta clásica que quede. Para más información, consulte Migrar una cuenta de almacenamiento clásica a Azure Resource Manager.

  • Cuentas de almacenamiento separadas por carga de trabajo, entorno y sensibilidad: Crea cuentas separadas para desarrollo, preproducción y producción, y cuentas separadas para datos de diferentes clasificaciones de sensibilidad. Una cuenta de almacenamiento constituye una frontera de confianza basada en claves compartidas y una frontera de directiva; mezclar cargas de trabajo en una sola cuenta aumenta el alcance de una vulneración y dificulta modelar el acceso con privilegios mínimos.

  • Utiliza una cuenta por región para aislamiento regional: Colocar cuentas en la región donde se ejecutan sus cargas de trabajo que consumen reduce el movimiento de datos entre regiones y simplifica los límites de cumplimiento. Para diseños multirregión, empareja cuentas regionales con almacenamiento geo-redundante o replicación de objetos en lugar de servir todas las regiones desde una sola cuenta. Para más información, vea Redundancia de Azure Storage.

Uso apropiado de Azure Storage

  • No uses las claves de cuenta de Azure Storage como credenciales de aplicación duradera: Las claves de cuenta de Storage otorgan control total sobre la cuenta y no pueden ser alcanzadas. Las aplicaciones deben usar Microsoft Entra ID con identidades administradas o, cuando Entra ID no sea una opción, tokens de firma de acceso compartido (SAS) de delegación de usuario y de corta duración. Para obtener más información, consulte Autorización de acceso a datos en Azure Storage.

  • No uses Azure Storage como un almacén de secretos de propósito general: los secretos, cadenas de conexión y certificados pertenecen a Azure Key Vault, que proporciona rotación, políticas de acceso, protección de módulos de seguridad de hardware (HSM) y rastreos de auditoría. Para más información, consulte Introducción a Azure Key Vault.

Seguridad de red

Las cuentas de almacenamiento son accesibles por internet por defecto. Reducir la superficie de ataque en red es el cambio más efectivo que puedes hacer para proteger una cuenta contra accesos no autorizados, exfiltración de datos y reconocimiento.

  • Desactiva el acceso público a la red a la cuenta de almacenamiento: Cuando tus clientes estén completamente en Azure o sean accesibles a través de Private Link, configura el acceso público de la cuenta en Deshabilitado para que solo se acepten las solicitudes a través de endpoints privados. Para más información, consulte Configuración de firewalls y redes virtuales de Azure Storage.

  • Utiliza puntos finales privados para acceder desde redes virtuales: Un punto final privado asigna una dirección IP privada desde tu red virtual a la cuenta de almacenamiento y enruta el tráfico a través de la columna vertebral de Microsoft. Combinado con el acceso público a la red desactivado, los endpoints privados eliminan la exposición a internet. Para obtener más información, consulte Uso de puntos de conexión privados para Azure Storage.

  • Restringir el acceso público con el cortafuegos de almacenamiento cuando los extremos privados no sean prácticos: Si los clientes deben acceder a la cuenta a través de redes públicas, configura la acción predeterminada del firewall en Denegación y permite solo los rangos de IP específicos, subredes virtuales de red (a través de endpoints de servicio) o instancias de recursos que necesiten acceso. Para más información, consulte Configuración de firewalls y redes virtuales de Azure Storage.

    • Permitir el acceso a la cuenta a los servicios de confianza de Microsoft cuando lo necesiten: Las reglas de firewall de denegación predeterminada bloquean las solicitudes de otros servicios de Azure (por ejemplo, Azure Backup, Log Analytics y Microsoft Defender for Storage), así como del portal de Azure y de las canalizaciones de diagnósticos. Añade la opción Permitir servicios de Azure en la lista de servicios de confianza para acceder a esta excepción de cuenta de almacenamiento, de modo que los servicios de primera mano en los que dependes puedan acceder a la cuenta sin abrirla a internet público. Para obtener más información, consulte Conceder acceso a servicios de Azure confiables.

    • Conceder acceso a instancias específicas de recursos en lugar de servicios confiables de forma general: Preferir las reglas de instancias de recursos, que autorizan un recurso de Azure nombrado y su identidad gestionada, frente a la excepción general "Permitir servicios confiables de servicios Microsoft". Las reglas de instancia de recursos producen una superficie de confianza más pequeña. Para más información, consulte Concesión de acceso desde instancias de recursos de Azure.

  • Asociar cuentas de almacenamiento con un perímetro de seguridad de red: Un perímetro de seguridad de red define límites lógicos entre recursos de plataforma como servicio y bloquea el tráfico fuera del perímetro por defecto, proporcionando una defensa en profundidad más allá de las reglas de cortafuegos por cuenta. Para más información, consulte Perímetro de seguridad de red para Azure Storage.

  • Exigir una versión mínima de TLS 1.2 o posterior: Configure la versión mínima de TLS de la cuenta de almacenamiento para rechazar clientes que intenten negociar versiones anteriores y obsoletas. Para más información, consulte Configurar la versión mínima requerida de Transport Layer Security (TLS) para una cuenta de almacenamiento.

  • Requerir transferencia segura (HTTPS): Habilitar que la propiedad requerida para la transferencia segura rechace cualquier solicitud realizada a través de HTTP. Este requisito se aplica tanto a los endpoints REST como al acceso SMB a Azure Files. Para más información, consulte Requerir transferencia segura para una cuenta de almacenamiento.

    • Algunos escenarios, como clientes antiguos de pymes o herramientas heredadas, requieren HTTP. En tales casos, aisla esos clientes en un segmento de red controlado y migra fuera de HTTP lo antes posible.

  • Restringir la replicación de objetos entre arrendatarios y las operaciones de copia: Configure la cuenta de almacenamiento para permitir las operaciones de copia y de replicación de objetos solo desde cuentas de origen del mismo arrendatario o solo desde cuentas de origen incluidas en una lista de permitidas. Esta configuración impide el movimiento de datos más allá de los límites del inquilino por parte de usuarios que poseen permisos del plano de datos. Para obtener más información, consulte Ámbito permitido para las operaciones de copia y Impedir la replicación de objetos entre los inquilinos de Microsoft Entra.

  • Utiliza etiquetas de servicio VNet para las reglas salientes a Azure Storage: Cuando restrinjas el tráfico saliente de una red virtual a Azure Storage, usa la Storage etiqueta de servicio (o variante específica de la región) en lugar de rangos IP codificados de forma fija. Microsoft mantiene la etiqueta de servicio a medida que evoluciona el espacio IP. Para obtener más información, consulte Azure service tags overview.

  • Prefiere la red global de Microsoft para el enrutamiento entrante: Configura la preferencia de enrutamiento de red de la cuenta de almacenamiento respecto al enrutamiento de red de Microsoft para que el tráfico entrante entre en la columna vertebral de Microsoft en el punto de presencia más cercano al cliente y permanezca en la red de Microsoft de extremo a extremo. El enrutamiento por Internet sale antes de la red de Microsoft y aumenta la exposición a la ruta de Internet pública. Para obtener más información, consulte Configuración de las preferencias de enrutamiento de red para Azure Storage.

Administración de identidades y acceso

Las cuentas de almacenamiento soportan dos modelos de autorización: Microsoft Entra ID (basado en identidad, auditable, revocable) y Clave Compartida (un secreto simétrico con acceso completo a la cuenta). Traslada las cargas de trabajo a Microsoft Entra ID siempre que sea posible y trata la clave compartida como un respaldo heredado.

  • Utiliza Microsoft Entra ID para autorizar el acceso a datos: La autorización Microsoft Entra ID utiliza tokens OAuth 2.0 e integra con Acceso Condicional, identidades gestionadas y auditorías RBAC. Es superior en todos los aspectos a la Clave Compartida para el acceso al plano de datos. Para obtener más información, consulte Autorización de acceso a datos en Azure Storage.

  • No permitir la autorización mediante clave compartida: Establece la propiedad allowSharedKeyAccess en false para que la cuenta rechace cualquier solicitud firmada con las claves de la cuenta. Solo se aceptan solicitudes de Microsoft Entra ID y, cuando corresponde, solicitudes SAS de delegación de usuario. Para obtener más información, consulte Impedir la autorización con clave compartida para una cuenta de Azure Storage.

  • Asigne roles RBAC con el ámbito más reducido posible: Asigne los roles integrados del plano de datos de Almacenamiento (por ejemplo, Lector de datos de blobs de Almacenamiento, Contribuidor de datos de colas de Almacenamiento) en el nivel de contenedor, recurso compartido, cola o tabla siempre que sea posible, en lugar de en el nivel de cuenta o suscripción. Para más información, consulte Autorizar acceso a blobs usando el control de acceso basado en roles de Azure.

    • Añadir condiciones ABAC para restringir aún más el acceso al plano de datos: el control de acceso basado en atributos de Azure (ABAC) permite adjuntar condiciones a asignaciones de roles, por ejemplo, restringir el acceso a blobs con una etiqueta de índice específica o bajo un prefijo de ruta específico. Para obtener más información, consulte Autorizar el acceso a blobs mediante asignaciones de roles de Azure con condiciones ABAC.

  • Utilice una SAS de delegación de usuario en lugar de una SAS de servicio o de cuenta cuando sea necesario usar SAS: Una SAS de delegación de usuario se firma con credenciales de Microsoft Entra en lugar de con la clave de la cuenta, por lo que revocar la clave de delegación de usuario invalida inmediatamente todas las SAS emitidas a partir de ella. Los tokens SAS de servicio y cuenta firmados con claves de cuenta no pueden revocarse individualmente. Para obtener más información, consulte Otorgar acceso limitado a recursos de Azure Storage con firmas de acceso compartido (SAS).

    • Asigna a cada SAS los permisos mínimos y la vida útil más corta requerida: concede solo las operaciones específicas (por ejemplo, read pero no write) y establece el plazo de expiración en una hora o menos para el SAS de servicio que no esté respaldado por una política de acceso almacenado. Para más información, consulta Mejores prácticas al usar SAS.

    • Configura una política de expiración SAS en la cuenta: Establece un límite superior para el periodo de validez de los tokens SAS emitidos desde la cuenta. Las violaciones se registran para que puedas encontrar y corregir SAS persistentes en tu base de código. Para más información, consulte Creación de una directiva de expiración para las firmas de acceso compartido.

    • Restringir los tokens SAS únicamente a HTTPS: Cuando debas emitir un token SAS, permite solo HTTPS en la firma del SAS para evitar la exposición del token SAS en texto claro. Para obtener más información, consulte Otorgar acceso limitado a recursos de Azure Storage con firmas de acceso compartido (SAS).

  • Si debes usar claves de cuenta, protégelas y rótalas: Almacena las claves de cuenta en Azure Key Vault, recupéralas en tiempo de ejecución en lugar de incrustarlas en la configuración y rótalas según una programación definida. Disponga de un procedimiento de rotación documentado que evite el tiempo de inactividad mediante el uso de ambas claves durante la rotación. Para obtener más información, consulte Administración de las claves de acceso de la cuenta de almacenamiento.

  • Asigne roles de almacenamiento con privilegios de forma puntual con Microsoft Entra Privileged Identity Management (PIM): Para los roles que permiten realizar cambios en el plano de administración del almacenamiento (como Colaborador de la cuenta de almacenamiento o Propietario), exija la activación de PIM con aprobación y autenticación multifactor en lugar de asignaciones permanentes. Para obtener más información, consulte ¿Qué es Microsoft Entra Privileged Identity Management?.

Protección de los datos

Azure Storage cifra todos los datos en reposo por defecto con claves gestionadas por Microsoft. Las recomendaciones de esta sección añaden control del cliente, protegen contra modificaciones accidentales o maliciosas y reducen la exposición de datos en tránsito y en reposo.

  • Configura las claves gestionadas por el cliente (CMK) para cifrado en reposo: Utiliza una clave que gestiones en Azure Key Vault o Managed HSM como clave de cifrado de cuenta. CMK te permite rotar, auditar y revocar la clave de cifrado de forma independiente a las claves gestionadas por Microsoft. Soporta requisitos de cumplimiento que exigen el control de las claves del cliente. Para obtener más información, consulte Claves administradas por el cliente para el cifrado de Azure Storage.

  • Habilitar el cifrado de infraestructura para doble cifrado de defensa en profundidad: El cifrado de infraestructura aplica una segunda capa de cifrado gestionada por servicios encima de la capa principal de cifrado. Debes activarlo al crear la cuenta. Para más información, consulte Habilitar cifrado de infraestructura para doble cifrado de datos.

  • Utiliza ámbitos de cifrado para aislar cifrado en contenedores o blobs específicos: Los ámbitos de cifrado permiten aplicar diferentes claves o políticas de rotación de claves a nivel de contenedor o blob, con granularidad dentro de una sola cuenta. Esta función es útil para cargas de trabajo multiinquilino que comparten una cuenta, pero necesitan control de claves para cada inquilino. Para más información, consulte Scope de cifrado para Blob Storage.

  • Activar el cifrado de Azure Storage para todos los datos en tránsito: Combinar Secure transfer required = enabled (ver seguridad de red) con una versión mínima TLS de 1.2 o posterior. Juntos se aseguran de que la cuenta rechace tanto conexiones no cifradas como débilmente cifradas.

  • Utiliza cifrado del lado del cliente para los datos más sensibles: Para datos cuyo texto plano nunca debe aparecer en el servidor, cifra el cliente antes de subirla. El cifrado del lado del cliente es complementario al cifrado del lado del servicio y puede usarse junto con CMK para protección en capas. Para soporte y patrones de SDK por servicio, véase artículos relacionados sobre seguridad.

  • Proteger la cuenta de almacenamiento con un bloqueo de recursos: Aplicar un bloqueo CanNotDelete o Solo Lectura para evitar la eliminación o reconfiguración accidental o maliciosa de la cuenta. Los bloqueos se aplican al recurso de la cuenta, no a los datos que contiene, por lo que complementan —no reemplazan— la eliminación suave y la inmutabilidad. Para más información, consulte Aplicación de un bloqueo de Azure Resource Manager a una cuenta de almacenamiento.

Para características específicas de protección de datos de servicios de datos (inmutabilidad de blob y políticas WORM, ámbitos de cifrado de blob), véase el subartículo correspondiente en Artículos relacionados de seguridad.

Registro y supervisión

Las cuentas de almacenamiento son objetivos frecuentes de robo de credenciales, intentos de exfiltración y mala configuración. Necesitas registros continuos y detección de amenazas para detectar y responder rápidamente a los ataques.

  • Habilitar Microsoft Defender para almacenamiento: Defender para almacenamiento proporciona detección de amenazas, escaneo de malware al subir en busca de blobs y descubrimiento de datos sensibles. Señala patrones de acceso anómalos, IPs maliciosas conocidas y salidas de Tor, así como actividades de autenticación inusuales. Actívalo a nivel de suscripción o cuenta de almacenamiento. Para más información, consulte Resumen de Microsoft Defender para Almacenamiento.

    • Habilitar el escaneo de malware para cargas de blobs en cuentas que aceptan contenido no confiable: El escaneo de malware inspecciona los blobs subidos y marca o elimina contenido malicioso antes de que pueda ser servido a los consumidores posteriores. Para más información, consulta Escaneo de malware en Defender para almacenamiento.

    • Habilitar la detección de amenazas de datos sensibles: El descubrimiento de datos sensibles clasifica los datos de la cuenta y prioriza las alertas en contenedores que contienen información sensible. Para más información, consulte Descubrimiento de datos sensibles en Defender for Storage.

  • Enviar la configuración de diagnóstico a un área de trabajo de Log Analytics: Configure la configuración de diagnóstico en la cuenta y en cada servicio de datos (Blobs, Files, Queues, Tables) para enviar los registros de StorageRead, StorageWrite y StorageDelete, así como todas las métricas, a Log Analytics. Conserva los registros durante el periodo requerido por tus obligaciones de cumplimiento. Para más información, consulte Supervisión de Azure Storage.

  • Auditar cómo se autoriza cada solicitud: Los registros de almacenamiento registran si cada solicitud fue autorizada con Microsoft Entra ID, Clave Compartida, SAS o de forma anónima. Consulta los registros regularmente para detectar métodos de autorización inesperados, especialmente el uso de clave compartida después de desactivarlo o el acceso anónimo después de desactivarlo. Para más información, consulte Monitorizar solicitudes contra Azure Storage.

  • Alerta en eventos de seguridad de alta señal: Configura alertas de Azure Monitor para eventos como regeneración de claves, cambios en reglas de firewall, cambios en el acceso público a la red, uso de claves compartidas en cuentas donde debería estar desactivada y alertas de Defender para almacenamiento. Para obtener más información, consulte Alertas de registro en Azure Monitor.

  • Reenviar registros a un SIEM central: Para una respuesta a escala empresarial, reenvía los registros de almacenamiento desde Log Analytics a Microsoft Sentinel u otro SIEM para que los eventos de almacenamiento se correlacionen con las señales de identidad, red y punto final. Para más información, consulta Connect Azure Storage to Microsoft Sentinel.

Cumplimiento y gobernanza

Los controles de gobernanza hacen que las configuraciones seguras sean predeterminadas y detectan deriva automáticamente. Para cualquier patrimonio de almacenamiento mayor que un puñado de cuentas, la aplicación basada en políticas es la única forma sostenible de mantener la línea base consistente.

  • Aplicar Azure Policy para hacer cumplir la seguridad básica del almacenamiento: Asigna políticas integradas que bloqueen configuraciones inseguras en el momento del despliegue y audita cuentas existentes. Entre los elementos integrados de alto valor se incluyen: exigir transferencia segura, exigir como mínimo TLS 1.2, denegar el acceso a redes públicas, denegar el acceso público a blobs, exigir cifrado de infraestructura y exigir CMK. Para una lista completa, consulte las definiciones integradas de Azure Policy para Azure Storage y Azure Policy Regulatory Compliance controls for Azure Storage.

  • Utiliza el benchmark de seguridad en la nube de Microsoft (MCSB) como referencia: alinea los controles de almacenamiento con los dominios MCSB v2 para mantener una postura de seguridad coherente entre servicios. Para más información, consulte Resumen del benchmark de seguridad en la nube de Microsoft.

  • Cuentas de almacenamiento de etiquetas con propietario, clasificación de datos y entorno: Las políticas de gobernanza, la gestión de costes y la respuesta a incidentes dependen de un etiquetado consistente. Aplica etiquetas a través de Azure Policy para que no se puedan omitir en el momento de creación.

  • Revisa las ofertas de cumplimiento antes de almacenar datos regulados: Azure Storage cuenta con certificaciones para marcos regulatorios comunes (HIPAA, PCI DSS, FedRAMP, ISO 27001 y otros). Confirma la cobertura de tu carga de trabajo antes del despliegue. Para más información, consulte las ofertas de cumplimiento de Azure Storage.

Copia de seguridad y recuperación

La redundancia interregional junto con procedimientos de failover validados proporcionan resiliencia regional para la propia cuenta de almacenamiento. Para obtener información sobre la protección contra el borrado específica de los servicios de datos (borrado temporal de blobs, control de versiones de blobs, feed de cambios, restauración a un momento determinado, borrado temporal de recursos compartidos de archivos e instantáneas), consulte el subartículo correspondiente en Artículos relacionados con la seguridad.

  • Elige una opción de redundancia adecuada para tus necesidades de recuperación: Almacenamiento geo-redundante (GRS/RA-GRS/GZRS/RA-GZRS) replica los datos a una región emparejada y soporta conmutación por error iniciada por el cliente para resiliencia regional. El almacenamiento redundante por zonas (ZRS/GZRS) protege contra fallos a nivel de zona dentro de una región. Para más información, vea Redundancia de Azure Storage.

  • No confíe en la georredundancia como protección frente al ransomware: la replicación georredundante duplica los datos, así como cualquier daño o eliminación malintencionada, en la región asociada. Combine GRS con directivas de inmutabilidad, borrado temporal y control de versiones para proteger contra el ransomware y la manipulación indebida. Para más información, consulte Funciones de protección de datos en Azure Storage.

  • Ponga en práctica la conmutación por error y la conmutación de vuelta iniciadas por el cliente: para cuentas con RA-GRS o RA-GZRS, realice un ejercicio de conmutación por error planificado para validar su procedimiento de recuperación antes de que lo necesite. Para obtener más información, consulte Recuperación ante desastres y conmutación por error de la cuenta de almacenamiento.

Para orientación de seguridad específica para cada servicio de datos de Azure Storage, véase:

Pasos siguientes

  • Se actualizó por última vez el