Microsoft AZ-500: Seguridad de datos, almacenamiento y bases de datos — Guía de estudio

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Forma parte de la Microsoft Azure Security Engineer Associate AZ-500 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Información general

La seguridad de los datos, el almacenamiento y las bases de datos de Azure se centra en minimizar la confianza, aislar los planos de datos, cifrar en todas partes y operacionalizar el privilegio mínimo con rutas de acceso auditables. Esta sección explica cómo fortalecer la seguridad (harden) de Azure Storage, Azure SQL y Azure Cosmos DB, elegir la estrategia de identidad y claves correcta, y prevenir la exfiltración de datos. Cada control descrito se acompaña del razonamiento operativo que lo respalda para que pueda justificar y mantener la configuración en producción.

Asegurar las cuentas de Azure Storage y el acceso a los datos

Autorización y uso compartido de cuentas de almacenamiento

• Azure RBAC para Azure Storage: Prefiera la autorización basada en Azure AD (Blob y Queue) a través de roles integrados como Storage Blob Data Reader/Contributor. Razonamiento: acceso basado en tokens y con límite de tiempo a través de Conditional Access, registrado en Entra ID; evita las claves de cuenta perpetuas y admite la asignación justo a tiempo (just-in-time).
• Claves compartidas: Las claves primarias/secundarias de la cuenta otorgan derechos completos sobre el plano de datos. Deshabilite el uso de claves en el código y rótelas con frecuencia. Razonamiento: las claves compartidas son secretos de portador (bearer secrets) sin vinculación de usuario o CA; una vulneración equivale a la exposición total de los datos.
• Tipos de SAS:
  • SAS de servicio: Otorga acceso con ámbito definido a recursos específicos (blob, file, queue, table) con permisos y límites de IP, protocolo y tiempo. Razonamiento: privilegio mínimo preciso para aplicaciones que no pueden usar tokens de AD.
  • SAS de cuenta: Superficie más amplia (p. ej., entre servicios); úsela con moderación. Razonamiento: expande el radio de impacto (blast radius) si se filtra.
  • SAS de delegación de usuario: Emitida usando Azure AD y una clave de delegación de usuario para Blob. Razonamiento: se vincula a la identidad de Azure AD y a CA; auditabilidad y revocación superiores.
• Políticas de acceso almacenadas: Definen restricciones reutilizables (vencimiento, permisos) para SAS en contenedores/recursos compartidos; revocar o actualizar la política invalida las SAS emitidas bajo ella. Razonamiento: revocación centralizada sin necesidad de regenerar los tokens integrados en los clientes.

Ejemplo: generar una SAS de delegación de usuario para un blob con Azure AD

az storage blob generate-sas \
  --account-name mystorage \
  --container-name data \
  --name report.csv \
  --permissions r \
  --expiry 2026-12-31T23:59Z \
  --as-user \
  --auth-mode login

Seguridad del servicio por tipo

• Blob/Queue/Table: Use Azure AD RBAC donde sea compatible (Blob, Queue). Establezca AllowBlobPublicAccess en false, requiera HTTPS, y habilite el control de versiones y la eliminación temporal (soft delete). Razonamiento: elimina las rutas de exposición anónimas y permite la recuperabilidad.
• Azure Files: Use Azure AD Kerberos para SMB con Entra ID (o integración con AD DS) y aplique permisos de privilegio mínimo a nivel de recurso compartido/archivo. Requiera el cifrado SMB. Razonamiento: acceso vinculado a la identidad con seguridad de transporte sobre SMB; sin claves compartidas en el espacio de usuario.
• Servicio Table: Use SAS con restricciones estrictas de IP/tiempo y evite las SAS de cuenta. Razonamiento: la granularidad a nivel de servicio no es tan rica; defina el ámbito de forma agresiva.

Aislamiento de red para todos los servicios de almacenamiento

• Reglas de firewall de almacenamiento: Restrinja a rangos de IP públicas seleccionados solo cuando Private Link no sea factible. Razonamiento: reduce la superficie de ataque, pero aún atraviesa la red pública de internet.
• Puntos de conexión privados (Private endpoints): Prefiera Private Link para Blob, Queue, Table y Files. Asigne zonas de DNS privado a nombres específicos de recursos. Establezca el acceso a la red pública en Deshabilitado (Disabled). Razonamiento: el tráfico permanece en la red troncal (backbone) de Azure; la identidad del recurso se valida a través de DNS privado; mitiga la exfiltración a servicios de apariencia similar.
• Puntos de conexión de servicio y políticas: Si Private Link no es una opción, habilite los puntos de conexión de servicio y aplique políticas de punto de conexión de servicio para restringir la salida (egress) a cuentas de almacenamiento específicas. Razonamiento: restringe el tráfico incluso en la salida de la red virtual; limita el riesgo de enviar datos a cuentas propiedad de atacantes.

Configuraciones operativas para estandarizar

• Exigir solo HTTPS, con un mínimo de TLS 1.2.
• Deshabilitar el acceso con clave compartida para Blob y Queue si se usa AD (depende del soporte de la característica).
• Políticas de inmutabilidad en contenedores/recursos compartidos críticos para la retención regulatoria y la resiliencia frente al ransomware.

Cifrado y gestión de claves

Capas de cifrado en reposo

• Claves administradas por el servicio (SMK): Cifrado predeterminado del lado del servidor administrado por Azure. Razonamiento: sobrecarga operativa nula; adecuado para muchas cargas de trabajo.
• Claves administradas por el cliente (CMK): Claves en Key Vault o Managed HSM para Storage, SQL y Cosmos DB. Razonamiento: límite de confianza externalizado, control del cliente sobre la rotación/revocación y evidencia para el cumplimiento normativo.
• Cifrado de infraestructura (doble cifrado): Capa adicional que utiliza claves separadas. Razonamiento: defensa en profundidad si se omite el cifrado del medio de almacenamiento o si se vulnera un límite criptográfico.

Rotación y operaciones de claves

• Las SMK rotan automáticamente; no se requiere ninguna acción.
• Las CMK se rotan creando una nueva versión de la clave, otorgando permisos de wrap/unwrap y volviendo a apuntar el recurso a la última versión (o a una referencia de clave sin versión cuando sea compatible). Razonamiento: rotación sin interrupciones con un cambio auditable.
• Proteja las claves con la eliminación temporal (soft delete) y la protección contra purga de Key Vault; controle la administración a través de RBAC y el plano de datos a través de políticas de acceso o RBAC (para Managed HSM, use RBAC). Razonamiento: previene la pérdida destructiva de claves y aplica el privilegio mínimo.

Ejemplo: establecer una CMK para una cuenta de almacenamiento

az storage account update \
  --name mystorage \
  --resource-group rg-secure \
  --encryption-key-source Microsoft.Keyvault \
  --encryption-key-vault /subscriptions/<subId>/resourceGroups/rg-secure/providers/Microsoft.KeyVault/vaults/mykv \
  --encryption-key-name stor-cmk

Ámbitos de cifrado (Encryption scopes)

• Use ámbitos de cifrado por contenedor en Storage cuando diferentes conjuntos de datos requieran claves distintas. Razonamiento: segmenta el radio de impacto y permite ciclos de vida de claves diferenciales.

Seguridad de la plataforma de base de datos: Azure SQL y Azure Cosmos DB

Autenticación y acceso en Azure SQL

• Autenticación con Microsoft Entra: Crear un administrador de Azure AD a nivel de servidor; usar usuarios de base de datos contenidos (CREATE USER FROM EXTERNAL PROVIDER). Justificación: evita los inicios de sesión/contraseñas de SQL y habilita el Acceso Condicional y PIM.
• Usuarios contenidos: La identidad reside en la base de datos, no en la master. Justificación: simplifica la georestauración y la conmutación por error sin necesidad de reaprovisionar inicios de sesión.
• Reglas de firewall: Evitar reglas de IP de cliente amplias; preferir Private Link con el acceso a la red pública deshabilitado. Si se requieren reglas de IP, limitarlas a direcciones exactas y automatizar su revisión. Justificación: reduce la superficie de ataque y el descubrimiento a través de puntos de conexión públicos.
• Puntos de conexión privados: Enrutar todo el tráfico del plano de datos a través de una VNet con DNS privado. Justificación: elimina la exposición y simplifica la prevención de la exfiltración de datos.
• Patrones de autenticación: Usar la autenticación integrada de Active Directory (para dispositivos unidos a un dominio) o el código interactivo/de dispositivo para obtener tokens; las cargas de trabajo de servicio deben usar identidades administradas. Justificación: elimina las contraseñas y habilita las políticas y la vida útil de los tokens.

Características de protección de datos

• Cifrado de datos transparente (TDE): Activado por defecto; cifra los datos, los registros y las copias de seguridad. Justificación: protege los medios en reposo sin cambios en la aplicación. Usar TDE con CMK para un control externalizado.
• Always Encrypted: Cifrado del lado del cliente para columnas sensibles con claves en Key Vault. Justificación: impide que los operadores de SQL o el motor vean el texto sin formato; usar para campos con PII/PCI.
• Enmascaramiento dinámico de datos (DDM): Ofusca los resultados de las consultas para usuarios no privilegiados. Justificación: reduce la exposición casual de datos pero no es un límite de seguridad; combinar con RBAC.
• Auditoría: Enviar a Log Analytics, Event Hubs o Storage. Justificación: crea un rastro inmutable para investigaciones y cumplimiento normativo.

Ejemplo: habilitar la auditoría a nivel de servidor hacia Log Analytics

az sql server audit-policy update \
  --name sql-secure \
  --resource-group rg-secure \
  --state Enabled \
  --log-analytics-workspace /subscriptions/<subId>/resourceGroups/rg-secure/providers/Microsoft.OperationalInsights/workspaces/la-secure

Microsoft Defender for SQL

• Evaluación de vulnerabilidades (VA): Establece líneas base y escanea el esquema y la configuración; exporta a almacenamiento; se integra con las puertas de DevSecOps. Justificación: higiene continua y detección de desviaciones con una guía de remediación clara.
• Detección de amenazas: Detecta inyección de SQL, inicios de sesión anómalos, inicio de sesión desde una ubicación no familiar y privilegios abusivos. Justificación: detección administrada con baja sobrecarga operativa; complementa los controles de red.
• Respuesta a alertas: Enrutar a Logic Apps, correo electrónico o SIEM. Crear playbooks para el triaje, la suspensión de usuarios, la revocación de tokens y el endurecimiento del firewall. Justificación: la respuesta codificada reduce el tiempo medio de contención.

Seguridad de Azure Cosmos DB

• Claves y tokens: Las claves primarias y secundarias son de alto privilegio; rotarlas regularmente. Preferir Azure AD RBAC para operaciones del plano de datos con roles como Cosmos DB Built-in Data Contributor/Reader. Justificación: acceso vinculado a la identidad con CA y auditoría.
• Controles de red: Lista de permisos del firewall de IP para contingencias; Puntos de conexión privados como la ruta por defecto; deshabilitar el acceso público si es factible. Justificación: control de ruta garantizado y validación del punto de conexión.
• Cifrado: En reposo por defecto; habilitar CMK para un control adicional. Justificación: cumple con los requisitos criptográficos externos y la separación de funciones.
• Registros de diagnóstico y métricas: Habilitar DataPlaneRequests, ControlPlaneRequests y categorías específicas de la API (p. ej., MongoRequests). Justificación: observabilidad de extremo a extremo para patrones de acceso, throttling y solicitudes anómalas.

Controles de monitoreo, clasificación y exfiltración

Secretos y cadenas de conexión respaldados por Key Vault

• Use identidades administradas para recuperar secretos/claves en tiempo de ejecución; nunca almacene secretos en el código o en la configuración. Justificación: elimina la proliferación de credenciales y la rotación de secretos en las aplicaciones.
• Referencia de Key Vault para App Service/Functions

ConnectionStrings__Sql=@Microsoft.KeyVault(SecretUri=https://mykv.vault.azure.net/secrets/sql-connstr/)

• Prefiera los tokens de acceso de Azure AD a SQL en lugar de las cadenas de conexión basadas en secretos cuando sea posible. Justificación: políticas y revocación más robustas.

Protección de la información y clasificación de datos

• Etiquetas de confidencialidad de Microsoft Purview Information Protection: Aplique etiquetas con cifrado y derechos de uso para documentos y correos electrónicos; integre con el etiquetado automático. Justificación: protección persistente más allá de los límites del almacenamiento.
• SQL Information Protection (Azure SQL): Use el descubrimiento y la clasificación de datos integrados, recomiende etiquetas en las columnas y exporte a Purview. Justificación: gobernanza centralizada y políticas consistentes en todo el patrimonio de datos.

Controles de exfiltración de datos y patrones de acceso seguro

• Priorizar Private Link: Para Storage, SQL y Cosmos DB. Deshabilite los puntos de conexión públicos. Justificación: previene el acceso desde la internet pública y fuerza a que el origen del tráfico esté en VNets aprobadas.
• Filtrado de egreso: Use Azure Firewall con etiquetas FQDN y reglas DNAT que solo permitan los puntos de conexión de Azure requeridos; agregue políticas de punto de conexión de servicio donde Private Link no sea práctico. Justificación: la lista blanca de salida (allow-listing) bloquea la fuga de datos hacia puntos de conexión controlados por atacantes.
• Reglas de instancia de recurso: Para el firewall de Storage, permita el acceso solo a instancias de recursos de confianza específicas (p. ej., un espacio de trabajo de Synapse). Justificación: vincula el acceso a productores/consumidores conocidos, no solo a redes.
• Fortalecimiento de SAS: Use SAS de delegación de usuario siempre que sea posible, limite a HTTPS, restrinja las IP, use permisos mínimos y tiempos de vida lo más cortos posible; vincule a políticas de acceso almacenadas para la revocación. Justificación: reduce el uso indebido de tokens y simplifica la invalidación de emergencia.
• AKS y puntos de conexión de servicio: Si depende de puntos de conexión de servicio, use Azure CNI para que los pods obtengan IP de la VNet y hereden el acceso del punto de conexión. Justificación: conecta el tráfico de contenedores con los controles nativos de la VNet; de lo contrario, los puntos de conexión no se aplican al tráfico de pods con NAT.
• Registro y análisis: Habilite los registros de diagnóstico de Storage, SQL y Cosmos DB en Log Analytics; cree alertas para volúmenes de datos anómalos, picos en la emisión de SAS y errores 403 frecuentes. Justificación: detección temprana de intentos de exfiltración.

Escenario de problema práctico

Spotify necesita prevenir la exfiltración de datos desde las subredes de los desarrolladores y las cargas de trabajo de AKS hacia puntos de conexión de Storage y SQL no autorizados, al tiempo que permite que los pipelines de CI/CD ejecuten pruebas de integración.

1. Deshabilite el acceso a la red pública y cree Private Endpoints para todas las cuentas de Storage y servidores de Azure SQL de producción. Justificación: Fuerza a que todos los flujos del plano de datos pasen por Private Link, eliminando el ingreso/egreso público y permitiendo una aplicación estricta del origen a través de VNets y DNS privado.

2. Configure zonas de DNS privado con registros A que mapeen los FQDN de los recursos de almacenamiento y base de datos a las IP de los puntos de conexión privados; vincule todas las VNets requeridas. Justificación: Previene la fuga de DNS hacia puntos de conexión públicos y asegura que los clientes resuelvan a los recursos privados previstos.

3. En los firewalls de Storage, agregue reglas de instancia de recurso solo para las identidades del clúster de AKS de producción y del conjunto de escalado de agentes de compilación; establezca la acción predeterminada en denegar. Justificación: Incluso dentro de la misma VNet, solo las identidades de recursos aprobadas pueden acceder a la cuenta, frustrando el movimiento lateral y la exfiltración desde cargas de trabajo no confiables.

4. Aplique Azure CNI en AKS y habilite puntos de conexión de servicio con políticas de punto de conexión de servicio para permitir que los namespaces de desarrollo alcancen únicamente una cuenta de almacenamiento dedicada de no producción. Justificación: Los pods de desarrollo obtienen IP de la VNet para que se apliquen las políticas de red; las políticas de punto de conexión restringen estrictamente cualquier tráfico no privado a las cuentas autorizadas.

5. Reemplace las claves compartidas con Azure AD RBAC para Blob y Queue en el código de la aplicación; cuando sea inevitable compartir para las pruebas, emita SAS de delegación de usuario con políticas de acceso almacenadas y una expiración de 1 hora. Justificación: Los tokens vinculados a una identidad son auditables y revocables; las SAS de corta duración minimizan el riesgo si un token se expone en los registros de compilación.

6. Habilite Defender for SQL con detección de amenazas y Vulnerability Assessment; enrute las alertas y los registros de auditoría de SQL a un espacio de trabajo central de Log Analytics con Logic Apps automatizadas para el triaje (deshabilitar usuario, revocar sesiones, agregar denegación temporal en el firewall). Justificación: Las detecciones administradas aceleran la contención de la inyección de SQL y el acceso anómalo, mientras que los playbooks estandarizan y agilizan la respuesta.

7. Use Key Vault para la CMK que protege los ámbitos de cifrado de TDE y Storage; habilite la eliminación temporal (soft delete) y la protección contra purga; rote las claves trimestralmente y actualice las referencias de los recursos a la última versión de la clave. Justificación: El control criptográfico externalizado con rotación segura cumple con la normativa y reduce el riesgo de errores operativos.

8. Clasifique las columnas sensibles en Azure SQL con SQL Information Protection e incorpórelas a Microsoft Purview; aplique etiquetas de confidencialidad de MIP para las exportaciones posteriores. Justificación: El etiquetado persistente viaja con los extractos de datos, lo que limita el uso indebido y permite que las herramientas de DLP apliquen controles en todas las herramientas y dispositivos.

9. Bloquee el egreso con Azure Firewall para permitir solo los servicios de Azure requeridos por la compilación/prueba, usando etiquetas FQDN para Storage y SQL y denegando el tráfico de salida HTTP(S) con comodines. Justificación: Un modelo de seguridad positivo asegura que el tráfico solo pueda llegar a los puntos de conexión aprobados, evitando que los datos salgan hacia dominios de atacantes.

Esta secuencia previene el acceso público, restringe tanto quién como qué puede acceder a los datos, vincula el acceso a identidades en lugar de a secretos y operacionaliza el monitoreo y la respuesta rápida, todo ello mientras se preserva la velocidad de los desarrolladores a través de excepciones acotadas y con límite de tiempo.

← Seguridad de computación · Todos los dominios · Gestión de claves →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Microsoft →