Diseñar protección de datos en AZ-305 es responder tres preguntas: ¿quién controla las claves (Microsoft o el cliente)? ¿de quién protegemos los datos (atacantes, administradores, el propio cloud provider)? ¿y cómo garantizamos que no se alteren ni borren?
Contenido
Platform-Managed Keys (PMK)
Customer-Managed Keys (CMK)
Cifrado de discos de VM
| Tecnología | Protege contra | Característica clave |
|---|---|---|
| TDE (Transparent Data Encryption) | Robo de archivos físicos de la DB / backups | Cifra toda la DB en reposo. ON por defecto. Transparente: los admins SQL VEN los datos en claro al consultar. CMK posible (BYOK) |
| Always Encrypted | Administradores de la DB y de Azure — los datos viajan cifrados hasta el cliente | Cifra COLUMNAS específicas; las claves las tiene el cliente. Ni el DBA ni Microsoft ven el dato. Limita queries (igualdad con deterministic). Con secure enclaves: rangos y LIKE |
| Dynamic Data Masking | Usuarios de la app que no deben VER el dato completo | NO cifra — enmascara en la presentación (XXX-XX-1234). Los datos siguen en claro en la DB. Control de exposición, no de seguridad criptográfica |
| Row-Level Security | Acceso entre filas de distintos tenants/usuarios | Filtra filas según el contexto del usuario — multi-tenant en una sola tabla |
La distinción que más cae
"Ni los administradores de base de datos ni Microsoft deben poder ver los números de tarjeta" → Always Encrypted (TDE no sirve: el DBA ve los datos). "Cifrar la base de datos y sus backups en reposo" → TDE. "El call center solo ve los últimos 4 dígitos" → Dynamic Data Masking.
En tránsito
En uso — Confidential Computing
| Mecanismo | Qué garantiza |
|---|---|
| Immutable blob storage — time-based retention | WORM: nadie (ni Owner) puede modificar/borrar blobs durante N días. Para SEC/FINRA y ransomware. Locked policy = irreversible |
| Immutable storage — legal hold | WORM sin fecha fija — hasta que se levante el hold (litigios) |
| Soft delete (blobs, containers, file shares) | Recuperar borrados accidentales durante la retención |
| Blob versioning | Cada sobrescritura crea versión recuperable |
| Point-in-time restore (block blobs) | Restaurar contenedores a un momento anterior |
| Resource lock CanNotDelete | Proteger la CUENTA contra borrado (plano de control) |
Señal anti-ransomware
"Los backups no deben poder ser cifrados ni borrados por un atacante con credenciales de administrador" → immutable storage con locked policy (o vaults de Azure Backup con immutability + soft delete always-on + multi-user authorization).
Microsoft Purview
En SQL
| Requisito | Diseño |
|---|---|
| La organización debe poder revocar las claves de cifrado del storage | CMK en Key Vault (+ purge protection) |
| Ni DBAs ni Microsoft ven los números de tarjeta | Always Encrypted en esas columnas |
| Cifrar DB y backups en reposo (compliance general) | TDE (default; CMK si piden control de clave) |
| Soporte ve solo últimos 4 dígitos del documento | Dynamic Data Masking |
| Cada tenant solo consulta sus propias filas | Row-Level Security |
| Registros financieros inalterables 7 años (WORM) | Immutable blob storage, time-based locked policy |
| Datos protegidos incluso durante el procesamiento | Confidential VMs / confidential computing |
| Descubrir PII en SQL, ADLS y S3 | Microsoft Purview |
| Cifrado dentro del SO de la VM (BitLocker) | Azure Disk Encryption |
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una fintech almacena números de tarjeta en Azure SQL Database. El requisito de cumplimiento dice: 'los datos de tarjeta no deben ser visibles para los administradores de la base de datos ni para el proveedor cloud, ni siquiera durante una consulta'. TDE ya está habilitado. ¿Qué falta?
Inicia sesión para llevar tu progreso.