En el examen DP-300, la sección de cumplimiento exige una habilidad concreta: saber qué característica de seguridad corresponde a cada escenario. El cifrado protege los datos, pero los organismos reguladores esperan más — quién consultó qué y cuándo, si las columnas sensibles están estructuralmente ocultas para quienes no tienen permisos, y si algún registro ha sido manipulado. Azure SQL Database aborda cada uno de estos requisitos en una capa diferente.
SQL Audit — Registrarlo Todo Como un Sistema de Videovigilancia
Un supermercado sin cámaras no tiene forma de reconstruir lo que ocurrió tras un robo. SQL Audit es el equivalente a instalar un circuito cerrado de televisión en la base de datos. Cada inicio de sesión, consulta y modificación de datos queda registrada en un log duradero que se puede presentar como evidencia durante una auditoría de cumplimiento.
Una política de auditoría a nivel de servidor se aplica automáticamente a todas las bases de datos de ese servidor, lo que resulta útil cuando un equipo gestiona muchas bases de datos y necesita una línea de base coherente. Una política a nivel de base de datos se limita a una única base de datos y puede ejecutarse junto con la política de servidor, o de forma independiente, para un control más granular.
Los logs de auditoría pueden enviarse a tres destinos: Storage Account, Log Analytics Workspace o Event Hub. Storage Account es adecuado para los requisitos de retención a largo plazo. Log Analytics permite ejecutar consultas Kusto de inmediato para investigaciones puntuales. Event Hub conecta los eventos de auditoría con pipelines de streaming en tiempo real. En los escenarios del examen, "presentar evidencias a largo plazo a un organismo regulador" apunta a Storage Account; "integrar con detección de anomalías en tiempo real" apunta a Event Hub.
Dynamic Data Masking — El Ticket con Datos Redactados
Cuando pagas en una cafetería, el recibo muestra únicamente los últimos cuatro dígitos de tu tarjeta. El número completo permanece en el sistema de pago; el papel impreso revela solo lo necesario para identificar la transacción. Dynamic Data Masking (DDM) funciona de la misma manera. El valor real permanece intacto en la base de datos; los usuarios sin los privilegios suficientes reciben una versión enmascarada en el momento de la consulta.
Existen cinco tipos de reglas de enmascaramiento. reemplaza números por 0, cadenas por X y fechas por 1900-01-01. expone la primera letra y el sufijo de dominio. combina un prefijo especificado, un bloque de caracteres X y un sufijo. sustituye el valor por un número aleatorio dentro de un rango definido. muestra un número específico de caracteres al principio y al final, enmascarando la parte central.
El punto más importante del examen sobre DDM es el permiso . Cualquier usuario al que se le conceda este permiso verá el valor original. Los administradores con el rol db_owner también omiten el enmascaramiento por completo. DDM controla únicamente la capa de presentación — no es un sustituto del control de acceso a nivel de motor. Cuando un escenario requiere "incluso el DBA no debe ver el texto en claro", la respuesta es Always Encrypted, no DDM.
Row-Level Security — Tarjetas de Acceso Distintas para Cada Planta
En la sede de una gran empresa, la tarjeta de acceso de un empleado de ventas abre la planta de ventas, pero no el laboratorio de I+D. Row-Level Security (RLS) aplica esta misma idea a las filas de una base de datos. Dos usuarios que consultan la misma tabla pueden recibir conjuntos de resultados completamente distintos según el contexto de sus sesiones.
RLS se construye a partir de dos piezas. Una — una función con valores de tabla en línea — codifica la lógica de "¿puede este usuario ver esta fila?". Una vincula esa función a la tabla de destino. Existen dos tipos de predicados. Un elimina silenciosamente del resultado de SELECT las filas que no superan la condición. Un también impide las operaciones INSERT, UPDATE y DELETE que violarían la política.
RLS se ve con mayor frecuencia en arquitecturas SaaS multiinquilino. Cuando una sola tabla contiene datos de muchos clientes, RLS garantiza que las consultas de cada cliente devuelvan solo sus propias filas, sin necesidad de tablas o vistas separadas por cliente.
Ledger — El Documento Notariado
Un documento notariado no puede modificarse después de que el sello es aplicado; cualquier cambio es inmediatamente detectable como una falsificación. Azure SQL Ledger aplica el mismo concepto a los registros de una base de datos. Una cadena de hash criptográficos protege el historial de cada tabla ledger. Si alguien modifica un registro antiguo fuera del flujo de escritura habitual, la verificación detectará la manipulación.
Existen dos tipos de tablas Ledger. Una permite modificaciones y eliminaciones, pero cada cambio se añade a una tabla de historial separada protegida por la cadena de hash. Una solo permite INSERT; UPDATE y DELETE están bloqueados a nivel de motor. Cuando una pregunta del examen menciona "detección de manipulación" o "prueba criptográfica de integridad de datos", Ledger es la respuesta.
Defender for SQL — El Vigilante en la Entrada
Un vigilante de seguridad en la entrada de una fábrica nota un vehículo desconocido o un patrón inusual de entradas y lo reporta de inmediato. Microsoft Defender for SQL analiza los patrones de consulta y el comportamiento de acceso para identificar automáticamente actividades anómalas.
Defender for SQL tiene dos capacidades. analiza configuraciones incorrectas, privilegios excesivos y vulnerabilidades conocidas sin parchear, y proporciona orientación para remediarlas. supervisa el comportamiento en tiempo de ejecución y genera alertas por intentos de inyección SQL, inicios de sesión desde ubicaciones inusuales y ataques de fuerza bruta. Si SQL Audit es "registrar lo que ocurrió", Defender for SQL es "alertar cuando algo parece sospechoso".
Comparación de los Controles de Seguridad
La superposición de varias características hace que sea fácil confundir qué herramienta se adapta a cada requisito. Piénsalo como una cocina con varios cuchillos: aunque se parecen, cada uno tiene un uso diferente. Always Encrypted se compara frecuentemente con DDM: DDM almacena el texto en claro en la base de datos y solo enmascara la salida, mientras que con Always Encrypted el propio servidor de base de datos nunca descifra los datos — solo el cliente que posee la clave de cifrado puede leer el texto en claro.
Para tener una referencia rápida de cada control: SQL Audit registra el historial de acceso sin concepto de omisión (evidencia de cumplimiento, rastro de auditoría). Dynamic Data Masking oculta el valor mostrado pero puede omitirse con el permiso UNMASK (ocultar columnas sensibles a usuarios de la app). Row-Level Security restringe el acceso a filas, pero db_owner lo omite (aislamiento multiinquilino, alcance por departamento). Always Encrypted no puede omitirse sin la clave de cliente (el servidor nunca ve el texto en claro). Ledger detecta la manipulación de inmediato (prueba de inmutabilidad criptográfica).
!Comparación de 4 controles de protección de datos
Trampas Prácticas — Omisión y Diseño en Capas
Depender de un único control crea brechas. DDM es efectivo para los usuarios habituales de la aplicación, pero no ofrece ninguna protección cuando un DBA se conecta directamente a través de SQL Server Management Studio — el enmascaramiento no se aplica. RLS tampoco se aplica a db_owner. Siempre que un escenario del examen indique "incluso los administradores no deben acceder al texto en claro", Always Encrypted es la respuesta requerida.
Ledger se especializa en la detección de manipulaciones, pero no proporciona control de acceso. Combinarlo con SQL Audit ofrece tanto un registro inmutable como un log de quién escribió ese registro. Defender for SQL es un servicio de detección de amenazas, no un mecanismo de enmascaramiento o bloqueo de acceso. Data Discovery & Classification analiza y etiqueta automáticamente las columnas sensibles; esas etiquetas alimentan luego las sugerencias de reglas DDM y el direccionamiento de las políticas de auditoría.
Resumen para el Examen
"Registrar quién ejecutó qué consulta y cuándo" -- SQL Audit "Retención a largo plazo de logs de auditoría para reguladores" -- destino Storage Account "Transmitir eventos de auditoría a un pipeline en tiempo real" -- destino Event Hub "Mostrar solo parte del número de tarjeta a los usuarios de la app" -- Dynamic Data Masking "Incluso el DBA no debe ver el texto en claro" -- Always Encrypted "Misma tabla pero cada departamento solo ve sus propias filas" -- Row-Level Security (FILTER predicate) "Permitir inserciones pero bloquear actualizaciones y eliminaciones" -- Append-only ledger table "Demostrar matemáticamente que ningún registro histórico fue manipulado" -- Azure SQL Ledger "Detección en tiempo real de intentos de inyección SQL" -- Defender for SQL (Advanced Threat Protection) "Analizar configuraciones incorrectas y permisos excesivos" -- SQL Vulnerability Assessment "Descubrir y etiquetar automáticamente columnas sensibles" -- Data Discovery & Classification "Aislar datos de clientes en una tabla multiinquilino" -- Row-Level Security
SQL Audit = registrar, DDM = enmascaramiento visual, RLS = aislamiento de filas, Ledger = prueba de integridad, Defender = detección de amenazas