AZ-104
Deep Dive
Las herramientas de Azure para proteger datos contra borrado accidental, ransomware y accesos no autorizados. El AZ-104 evalúa versioning, soft delete, inmutabilidad, cifrado con claves propias y Microsoft Defender for Storage.
Contenido
Azure Blob Storage ofrece múltiples capas de protección que pueden activarse independientemente. Se recomienda combinarlas para defensa en profundidad: Versioning + Soft Delete + Immutability.
| Feature | Protege contra | Nivel | Recuperación |
|---|---|---|---|
| Blob Versioning | Sobrescritura accidental de datos | Blob individual | Promover versión anterior a versión actual |
| Blob Snapshots | Backup manual punto en el tiempo | Blob individual (manual) | Copiar snapshot a blob base |
| Soft Delete (blob) | Borrado accidental de blob o versión | Blob individual | Undelete dentro del período de retención |
| Soft Delete (container) | Borrado accidental de container | Container completo | Restore container dentro del período |
| Immutable Storage | Borrado/modificación (compliance, ransomware) | Container o cuenta | No aplica — datos no pueden borrarse hasta que expire |
| Point-in-time restore | Corrupción masiva de datos, ransomware | Cuenta completa (blobs de bloque) | Restaurar todos los blobs a un punto anterior |
Blob Versioning (automático)
Cuando versioning está habilitado, cada escritura (PUT, COPY, overwrite) a un blob crea automáticamente una nueva versión. La versión actual es siempre la más reciente. Las versiones anteriores se retienen indefinidamente (o se eliminan con lifecycle policies).
Blob Snapshots (manual)
Un snapshot es una copia de solo lectura del blob en un momento específico. A diferencia de versioning (automático), los snapshots se crean manualmente o via API. El snapshot es inmutable — no puede modificarse.
Versioning vs Snapshots — cuándo usar cada uno
Usar Versioning cuando:
Usar Snapshots cuando:
Soft Delete para Blobs
Cuando se elimina un blob, se retiene en estado "deleted" durante el período de retención configurado (1-365 días). Se puede restaurar dentro de ese período.
Soft Delete para Containers
Protege el container completo (y todos los blobs dentro). Si alguien elimina un container entero, se retiene el container con todos sus blobs durante el período configurado.
WORM (Write Once, Read Many) impide que los datos sean modificados o eliminados durante un período. Crucial para compliance regulatorio: SEC 17a-4, FINRA, HIPAA.
Time-based Retention Policy
Los blobs no pueden ser eliminados ni modificados durante el período de retención definido (en días). Después del período, se pueden eliminar normalmente.
Unlocked
Configurable — puede extenderse (no reducirse) o eliminarse
Locked
Irrevocable — no puede desactivarse ni reducir el período. Requerido para compliance SEC 17a-4.
Legal Hold Policy
Retención indefinida sin período definido. Los datos no se pueden eliminar hasta que se levante el legal hold explícitamente. Usado para litigios o investigaciones.
Activo
Blobs no pueden eliminarse ni modificarse hasta que se elimine el tag de legal hold
Múltiples tags
Un container puede tener múltiples legal holds por diferentes casos/proyectos
Niveles de aplicación de la política
Container-level
Aplica a todos los blobs del container. Configurado en el container.
Version-level (por defecto)
Cada versión del blob tiene su propia inmutabilidad. Más granular.
Account-level (default retention)
Política de retención por defecto para todos los nuevos containers de la cuenta.
Always Encrypted
Cifrado end-to-end donde las claves NUNCA salen del cliente. El motor de SQL solo ve datos cifrados — ni siquiera los admins de BD pueden ver los datos en claro.
La clave maestra (Column Master Key) vive en el cliente (certificado Windows, Azure Key Vault). El motor recibe datos ya cifrados.
Datos ultra-sensibles: números de tarjeta, SSN, contraseñas. Requiere cliente compatible (ODBC, JDBC con el driver correcto).
Transparent Data Encryption (TDE)
Cifrado en reposo de la BD, backups y log files. El motor cifra/descifra automáticamente — la app no necesita cambios.
A diferencia de Always Encrypted, con TDE el motor de BD puede ver los datos en claro (los descifra para procesarlos). Protege el almacenamiento físico, no el acceso al motor.
Protección base para cualquier BD. Habilitado por defecto en Azure SQL.
Row-Level Security (RLS)
Controla acceso a filas basado en el usuario que ejecuta la query. Las filas invisibles al usuario simplemente no aparecen en los resultados — sin errores.
Implementado con Security Policies y funciones de predicado T-SQL. Transparente a la aplicación.
Multi-tenant: cada tenant solo ve sus propias filas sin cambios en la app.
Dynamic Data Masking (DDM)
Enmascara columnas para usuarios sin privilegio. El dato real existe y los usuarios con permiso lo ven completo.
No es cifrado — es presentación. Los datos reales siguen en la BD sin cifrar. Un DBA siempre ve el dato real.
Limitar exposición de datos sensibles a soporte técnico o reports de bajo privilegio.
Azure Key Vault centraliza la gestión de claves criptográficas, secretos y certificados. Es la pieza central de la estrategia de seguridad de datos en Azure.
Secrets
Cadenas de texto: connection strings, API keys, contraseñas. Versionados. Pueden tener fecha de expiración.
db_connection_string: Server=sql.database.windows.net;...
Keys
Claves criptográficas (RSA, EC). Las operaciones se realizan dentro del HSM — la clave nunca sale de Key Vault en texto plano.
Customer-managed key para Storage Account, SQL TDE, Cosmos DB CMK
Certificates
Certificados TLS/SSL. Gestiona creación, renovación automática con Let's Encrypt o CAs propias.
Certificado TLS para App Service o Application Gateway
Tiers de Key Vault
Standard
Software-protected keys. Las claves se almacenan en software cifrado dentro del servicio. Menos costo.
Premium
HSM-protected keys. Las claves se generan y almacenan en Hardware Security Modules certificados FIPS 140-2 Level 2. La clave nunca sale del HSM.
Managed HSM
HSM dedicado single-tenant. FIPS 140-2 Level 3. Control total — ni Microsoft puede acceder. Para requisitos de compliance máximos.
Control de acceso a Key Vault
Plano de gestión (quién puede administrar el vault):
→ Azure RBAC: Key Vault Contributor, Reader (control de configuración)
Plano de datos (quién puede usar secretos/claves):
→ RBAC (recomendado): Key Vault Secrets User, Key Vault Crypto User, Key Vault Certificates Officer
→ Access Policies (legacy): permisos granulares por principal (Get, List, Set, Delete, etc.)
Best practice: Managed Identity + Key Vault
En lugar de guardar secretos en la app o en variables de entorno: asigna una Managed Identity a la VM/App Service, da a esa identidad el rol Key Vault Secrets User sobre el vault, y la app lee los secretos directamente sin credenciales en el código.
Microsoft Defender for Storage
Detecta patrones anómalos de acceso a Storage Accounts: descarga masiva de datos, acceso desde TOR, hash de malware conocido en archivos subidos (Malware Scanning).
Microsoft Defender for SQL
Incluye Advanced Threat Protection (ATP) y Vulnerability Assessment. Detecta actividades anómalas y evalúa la postura de seguridad de la BD.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa del sector financiero necesita almacenar registros de transacciones en Blob Storage de forma que no puedan ser modificados ni eliminados durante 7 años, cumpliendo con requisitos regulatorios. ¿Qué configuración deberían usar?