Cuentas de Azure Storage

Una Azure Storage Account es el recurso fundamental que proporciona acceso a los servicios de almacenamiento principales de Azure: Blob Storage (almacenamiento de objetos), Azure Files (recursos compartidos de archivos administrados), Queue Storage (colas de mensajes), Table Storage (almacén NoSQL de pares clave-valor) y Azure Data Lake Storage Gen2 (espacio de nombres jerárquico para análisis). Una sola cuenta de almacenamiento puede alojar todos estos servicios simultáneamente y proporciona un espacio de nombres único en Azure: el nombre de la cuenta forma parte de la URL de cada objeto que contiene.

Azure ofrece varios tipos de cuentas de almacenamiento: Standard general-purpose v2 (GPv2) — el tipo recomendado para la mayoría de los escenarios; admite todos los servicios de almacenamiento y las opciones de redundancia con rendimiento estándar. Premium block blobs — almacenamiento respaldado por SSD para escenarios que requieren una latencia muy baja en las operaciones de Blob Storage. Premium file shares — recursos compartidos de Azure Files respaldados por SSD para cargas de trabajo con muchos IOPS, como bases de datos o directorios principales. Premium page blobs — almacenamiento SSD para los discos del sistema operativo y de datos de las VMs de Azure (Managed Disks lo utiliza internamente). Para la mayoría de los casos de uso, comience con una cuenta Standard GPv2.

Azure Storage replica sus datos automáticamente para protegerlos frente a fallos de hardware. Las cuatro opciones de redundancia son: LRS (Locally Redundant Storage) — tres copias síncronas dentro de un único centro de datos. ZRS (Zone-Redundant Storage) — tres copias síncronas distribuidas entre tres zonas de disponibilidad de una región. GRS (Geo-Redundant Storage) — LRS en la región primaria más replicación asíncrona a una región secundaria (LRS). GZRS (Geo-Zone-Redundant Storage) — ZRS en la región primaria más replicación asíncrona a una región secundaria. Una mayor redundancia implica una mayor durabilidad y un coste más elevado.

Elija el nivel de redundancia según sus requisitos de RTO, RPO y presupuesto: LRS — es la opción más económica, ofrece una durabilidad de 11 nueves y no protege frente a fallos del centro de datos. Úsela para desarrollo y pruebas, o para datos que pueda volver a crear. ZRS — protege frente a fallos del centro de datos y es adecuada para datos de producción en una sola región. GRS/GZRS — protege frente a la interrupción completa de una región de Azure; los datos se replican asíncronamente en la región emparejada. Para datos empresariales críticos que deban sobrevivir a un desastre regional, GRS o GZRS es la opción adecuada a pesar del coste adicional.

Azure Storage ofrece dos niveles de rendimiento: Standard — respaldado por unidades de disco duro (HDD), adecuado para la mayoría de las cargas de trabajo con un coste menor por GB. Premium — respaldado por unidades de estado sólido (SSD), diseñado para escenarios sensibles a la latencia que requieren operaciones de E/S de milisegundos de un solo dígito. El almacenamiento Standard se factura por cada GB almacenado; Premium es más caro por GB, pero ofrece un rendimiento uniforme y predecible. Para recursos web, copias de seguridad, registros y archivado, Standard es adecuado. Para VMs con bases de datos con uso intensivo de E/S o recursos compartidos de archivos a los que acceden usuarios de escritorio, Premium es la mejor opción.

Los nombres de las cuentas de almacenamiento deben ser globalmente únicos en todo Azure (porque forman parte de un nombre DNS público como mystorageacct.blob.core.windows.net). Deben tener entre 3 y 24 caracteres y contener únicamente letras minúsculas y números; no se permiten guiones, guiones bajos ni mayúsculas. Como los nombres deben ser globalmente únicos, las palabras comunes y los nombres de marcas ya suelen estar ocupados. Una buena práctica consiste en combinar un prefijo de la empresa, el entorno (prod/dev) y la finalidad (store/media), y añadir después un sufijo aleatorio si es necesario; por ejemplo, contosoprodmedia7x2.

Cada cuenta de almacenamiento tiene dos claves de acceso de 512 bits que conceden acceso administrativo completo a todo lo que contiene la cuenta. Estas claves deben tratarse como contraseñas y almacenarse en Azure Key Vault, no en el código ni en archivos de configuración. Azure genera dos claves para que pueda realizar una rotación de claves sin tiempo de inactividad: actualice sus aplicaciones para que utilicen Key 2, regenere Key 1, cambie las aplicaciones para que utilicen Key 1 y, a continuación, regenere Key 2. Para obtener un control de acceso más específico, use Shared Access Signatures (SAS) o Azure RBAC en lugar de compartir las claves maestras.

Azure RBAC (Role-Based Access Control) es la forma recomendada de autorizar el acceso a los datos de almacenamiento sin compartir claves. Asigne el rol Storage Blob Data Reader para permitir acceso de solo lectura a Blob Storage, o Storage Blob Data Contributor para permitir lectura y escritura. Estos roles se asignan a usuarios, grupos o identidades administradas de Entra ID, por lo que el acceso queda vinculado a una identidad autenticada en lugar de a un secreto compartido. La autorización mediante RBAC para almacenamiento está disponible en los servicios Blob, Queue y Table (no en File, que utiliza los protocolos SMB/NFS con sus propios controles de acceso).

De forma predeterminada, las cuentas de almacenamiento aceptan conexiones desde cualquier red. Para proteger un entorno de producción, restrinja el acceso mediante el Storage Account Firewall: permita únicamente rangos de IP públicas o subredes de redes virtuales específicos. Para obtener el máximo nivel de seguridad, deshabilite por completo el acceso a Internet público y use un Private Endpoint: una dirección IP privada dentro de su VNet que enruta el tráfico a la cuenta de almacenamiento a través de la red troncal privada de Azure, sin exponerla nunca en Internet público. Los Private Endpoints son el enfoque recomendado para las cuentas de almacenamiento que contienen datos confidenciales o sujetos a normativas.

Azure Storage proporciona funciones integradas de protección de datos para evitar eliminaciones accidentales: Blob soft delete — los blobs y las versiones eliminados se conservan durante un periodo configurable (de 1 a 365 días) y pueden recuperarse sin restaurarlos desde una copia de seguridad. Blob versioning — cada sobrescritura crea una versión nueva, por lo que puede restaurar cualquier versión anterior de un blob. Container soft delete — los contenedores eliminados accidentalmente pueden recuperarse. Estas funciones están deshabilitadas de forma predeterminada y deben habilitarse en las cuentas de almacenamiento de producción que contengan datos importantes no respaldados en otro lugar.

Azure Monitor recopila automáticamente métricas de cada cuenta de almacenamiento: capacidad total utilizada, número de transacciones, bytes de entrada y salida, y latencia de extremo a extremo. Puede verlas en el panel Insights del portal de Azure correspondiente a su cuenta de almacenamiento, que proporciona gráficos prediseñados de capacidad, disponibilidad y rendimiento. Para realizar auditorías detalladas de acceso, habilite Storage Diagnostic Logs para registrar cada operación de lectura, escritura y eliminación en un destino de registros; resulta útil para investigaciones de seguridad y la generación de informes de cumplimiento.

Compruebe sus conocimientos sobre los conceptos de Microsoft Azure Fundamentals (AZ-900) tratados en esta lección.

En esta lección ha aprendido que una cuenta de almacenamiento es el recurso raíz de todos los servicios de almacenamiento de Azure y se identifica mediante un nombre globalmente único; las opciones de redundancia —LRS, ZRS, GRS y GZRS— ofrecen niveles cada vez mayores de durabilidad con un coste también creciente; y el acceso debe controlarse mediante RBAC y puntos de conexión privados, en lugar de compartir las claves de acceso maestras. A continuación, profundizaremos en Blob Storage, el almacenamiento de objetos de Azure para datos no estructurados.