En las cuatro primeras partes de esta serie, planteamos una tesis contundente: la detección es el pilar fundamental de la seguridad. La prevención por sí sola es una quimera, incluso en teoría, ya que resulta imposible ajustarla con la suficiente sensibilidad sin causar problemas operativos. Los falsos positivos en los mecanismos de prevención pueden impedir que los usuarios realicen su trabajo, reducir la productividad o incluso provocar la corrupción de los datos. Es imprescindible contar con capacidad de detección; no saber qué ocurre dentro de tu base de datos equivale a haber perdido la batalla de antemano.

Sin embargo, priorizar la detección no significa dejar la puerta abierta de par en par ni convertir la base de datos en un entorno sin control alguno.

Una prevención eficaz no consiste en erigir un muro perfecto alrededor de la base de datos bajo la falsa premisa de que nadie podrá superarlo. Se trata, más bien, de imponer restricciones estrictas sobre aquellos vectores de actividad que, sencillamente, no deberían existir. No es necesario bloquearlo todo; basta con bloquear aquello que es factible impedir en la práctica, lo cual permite eliminar vectores de ataque significativos. En otras palabras, el objetivo es reducir sustancialmente la superficie de ataque, no alcanzar una seguridad absoluta. Todo lo demás depende de la detección.

Antes de profundizar en cómo implementar mecanismos de bloqueo eficaces, analicemos las limitaciones de la seguridad en bases de datos. Existe un mito muy extendido al respecto que debemos abordar para comprender el verdadero propósito del bloqueo.

Por Qué Falla la Seguridad Nativa de las BBDD

Si consultas el manual de cualquier proveedor de bases de datos, encontrarás cientos de páginas dedicadas a los controles de acceso nativos: usuarios, contraseñas, roles, privilegios del sistema, permisos sobre tablas y concesiones a nivel de columna. Para la mayoría del personal encargado de las bases de datos y la seguridad, eso es lo que significa la seguridad de las bases de datos.

En la práctica, los permisos nativos de las bases de datos son prácticamente inútiles para detener ataques reales.

A continuación el por qué:

1. La Falacia de la Autenticación

Los sistemas de autenticación, como los que emplean usuarios y contraseñas, verifican las credenciales. Sin embargo, no comprueban si la persona o el proceso que utiliza dichas credenciales es realmente quien dice ser. Esta brecha es el origen de muchos ataques.

Cuando un atacante roba una cadena de conexión válida de un servidor de aplicaciones comprometido, o bien obtiene la contraseña de un administrador de bases de datos (DBA) del archivo donde este la ha guardado, el sistema de autenticación nativo le abre la puerta de par en par. Para la base de datos, una credencial robada es indistinguible de una legítima.

Incluso aquellos ataques que no suplantan la identidad de un usuario real hacen uso de credenciales legítimas; ya sea porque el propio usuario es el atacante (abuso de privilegios) o porque el programa que utiliza las credenciales ha sido manipulado (por ejemplo, mediante una inyección SQL).

En cualquier caso, todos los ataques se valen de conexiones autenticadas legítimas. No es posible eludir una validación adecuada para acceder a la base de datos mediante «paquetes mágicos»; sencillamente, no existen.

En otras palabras: aunque el sistema de autenticación de la base de datos funcione exactamente según lo diseñado, todos los vectores de ataque logran superarlo, lo que provoca que las bases de datos sean vulneradas a diario.

2. La Cuenta de Aplicación

En la década de 1970, los diseñadores de seguridad de los motores de bases de datos establecieron permisos a nivel de tabla y columna, partiendo de la premisa de que cada individuo posee una cuenta —que contiene toda su información— y que comparte dichos datos con otras personas.

La arquitectura de software moderna ha roto por completo este modelo.

Hoy en día, el 99 % de la actividad en una base de datos proviene de un número reducido de cuentas de servicio de aplicaciones. Estas cuentas son propietarias de todos los datos, y las aplicaciones requieren este acceso total. Por tanto, la aplicación implementa sus propios controles de seguridad en el código que se ejecuta en los servidores de aplicaciones, no en la base de datos.

Si un usuario malintencionado se conecta a la base de datos utilizando estas cuentas, la base de datos carece de restricciones de seguridad que protejan la información. Del mismo modo, cuando los atacantes explotan una vulnerabilidad en la aplicación, la seguridad de la base de datos resulta inexistente.

3. El Administrador de BBDD (DBA) Sin Restricciones

La segunda categoría principal de cuentas activas en una base de datos corresponde a los administradores (DBA). Estos requieren privilegios elevados para gestionar el sistema; sin embargo, el modelo nativo de control de acceso otorga, además, un acceso ilimitado a los datos a dichas cuentas administrativas.

Al conceder a los DBA los permisos necesarios para el mantenimiento de la base de datos, se les otorga —a ellos, o a cualquier atacante que suplante su identidad— acceso total a toda la información almacenada en la base de datos.

Cerrando la Brecha

Los controles de acceso nativos resultan ineficaces porque la forma en que utilizamos las bases de datos otorga acceso total a casi todo el mundo. El bloqueo de SQL añade una capa adicional de reglas sobre los permisos nativos. Estas reglas incorporan más dimensiones y permiten aplicar restricciones que los controles nativos no pueden implementar.

El Vector de Amenaza Asociado a los DBA

Las cuentas privilegiadas de bases de datos representan el mayor riesgo y constituyen los objetivos de mayor valor dentro de una organización. Estas cuentas poseen todas las «llaves» de acceso, y los atacantes son plenamente conscientes de ello. La amenaza no proviene únicamente de administradores malintencionados; también incluye a atacantes externos que aprovechan el robo de credenciales o la toma de control de sistemas (compromiso C2).

No obstante, la función de un administrador de bases de datos es gestionar la infraestructura, no acceder a los datos. Mediante la aplicación de reglas de bloqueo SQL que impidan el acceso a la información, es posible eliminar gran parte del riesgo asociado a estos perfiles sin afectar a sus tareas diarias.

Regla 1: Restringir el acceso a los datos

Los administradores de bases de datos se encargan de gestionar el espacio, el rendimiento, las copias de seguridad, etc. Ninguna de estas tareas requiere leer información de identificación personal (PII) de los clientes ni modificar registros financieros.

Una regla de bloqueo SQL sencilla puede solucionar este problema: impedir que las cuentas de administrador ejecuten cualquier sentencia que no sea de tipo DDL (lenguaje de definición de datos) sobre los esquemas que contienen información.

Es posible aplicar distintas estrategias de aislamiento según la naturaleza de los datos; por ejemplo, bloqueando únicamente las consultas (queries) o las operaciones DML (lenguaje de manipulación de datos). En cualquier caso, separar las cuentas privilegiadas del acceso a los datos constituye un principio sólido y eficaz.

Esto no significa que los administradores no deban acceder nunca a los datos —por ejemplo, en situaciones como la reparación de entradas dañadas—, pero tales casos representan una excepción a la norma. Estas situaciones deben gestionarse de forma individual mediante una autorización temporal y específica, en lugar de conceder un acceso ilimitado y permanente.

Bloquear el acceso a los esquemas de datos desde cuentas administrativas protege a la organización frente a administradores malintencionados y anula la utilidad de las credenciales robadas para la exfiltración de información.

Regla 2: Bloqueo de Operaciones DML

Los administradores de bases de datos (DBA) rara vez —o nunca— deberían ejecutar sentencias INSERT, UPDATE o DELETE en entornos de producción. Las modificaciones de datos deben realizarse dentro de flujos de trabajo de aplicaciones debidamente protegidos. Permitir que los DBA ejecuten operaciones DML directamente en producción abre la puerta a errores humanos, corrupción de datos y manipulaciones deliberadas.

El bloqueo de SQL puede impedir la ejecución de operaciones DML provenientes de cuentas administrativas. Al igual que con el acceso a los datos, cualquier excepción debe gestionarse a través de un flujo de trabajo temporal y sujeto a auditoría; no debe tratarse de un permiso permanente que otorgue carta blanca.

Regla 3: Separación de Funciones

Las operaciones administrativas críticas, como la creación de usuarios o la concesión de permisos, deben estar sujetas a un proceso de control de cambios. Sin embargo, los registros de control de cambios no son más que documentos de texto que no pueden evitar que un atacante utilice una sesión robada, por ejemplo, a las 2 de la madrugada.

Al combinar el bloqueo de SQL con reglas de excepción (o «amnistía»), es posible implementar un flujo de trabajo que exija a los DBA obtener una autorización previa por parte del personal de seguridad antes de realizar determinadas acciones críticas. Por ejemplo:

• Un gerente genera un ticket solicitando un nuevo usuario de base de datos.
• El personal de seguridad valida la solicitud y emite un «código de amnistía» (Amnesty Code).
• El administrador de bases de datos (DBA) utiliza dicho código para eludir la regla de bloqueo que impide la creación de usuarios.
• El personal de seguridad recibe una notificación sobre las acciones realizadas mediante el uso de este código y procede a validarlas.

Esto transforma un privilegio estático y vulnerable en un proceso de autorización dinámico que involucra a varias partes. Evita acciones maliciosas por parte de los administradores de bases de datos (DBA) y, lo que es más importante, impide que los atacantes abusen de estas cuentas.

La Cuenta de Aplicación

Las cuentas de aplicación representan una pesadilla de seguridad, ya que poseen acceso total al esquema de datos. Si los atacantes logran extraer la cadena de conexión del servidor de aplicaciones, pueden conectarse directamente a la base de datos, eludiendo así por completo la seguridad de la aplicación.

El bloqueo de SQL puede mitigar este riesgo estableciendo barreras adicionales en torno a la cuenta de aplicación y a sus datos.

Vinculación con la Fuente de Actividad

La cuenta de aplicación solo debe ejecutar comandos SQL cuando se cumplan simultáneamente tres condiciones:

1. Utiliza las credenciales correctas (usuario y contraseña). No es necesaria seguridad adicional en este punto, ya que el motor de base de datos se encarga de validarlas.
2. Proviene de una dirección IP autorizada, correspondiente a un servidor de aplicaciones. La mayoría de las bases de datos no pueden verificar este aspecto.
3. La conexión se establece desde una aplicación legítima (por ejemplo, app1.exe) y no desde un cliente interactivo, como SQL Plus, Management Studio o un script de Python.

Si una conexión utiliza credenciales de aplicación válidas provenientes del equipo de un desarrollador, o si se origina a partir de un proceso no autorizado en el propio servidor de aplicaciones, el bloqueo de SQL interrumpe el tráfico de inmediato, otorgando al personal de seguridad tiempo para tomar medidas adicionales.

Protección del Núcleo Sensible

Es posible llevar la vinculación de origen (source binding) un paso más allá mediante la creación de un microperímetro dedicado en torno a tablas que contienen información sensible (por ejemplo, datos de pago o información de identificación personal, PII).

Incluso en aplicaciones complejas, no todos los microservicios o nodos web requieren acceso a las tablas que conforman el núcleo sensible. El bloqueo de SQL permite proteger tablas específicas restringiendo el acceso a cuentas, direcciones IP y programas determinados.

Estas restricciones estrictas garantizan que ninguna otra cuenta (ya sea de aplicación, de administrador de bases de datos o de analista), servidor o programa pueda acceder a información crítica.

El aislamiento puede aplicarse específicamente a consultas o a operaciones de manipulación de datos (DML), según la naturaleza de la información. Por ejemplo, en el caso de datos financieros, se debe evitar cualquier modificación no autorizada, mientras que, para la información de identificación personal (PII), es necesario restringir las consultas.

Mecanismos de Control Avanzados

Más allá de ampliar la seguridad tradicional mediante límites basados ​​en el origen de la actividad y el contenido de las sentencias SQL, el bloqueo avanzado de SQL incorpora mecanismos de control (guardrails) activos que operan en función del tiempo y el volumen de datos.

Ventanas Temporales

El acceso no autorizado a bases de datos suele producirse fuera del horario de funcionamiento habitual. Las empresas operan las 24 horas del día, los 7 días de la semana, pero el personal especializado generalmente trabaja durante el horario laboral estándar. Esto significa que, por lo general, es posible bloquear la actividad fuera de dicho horario o, al menos, limitarla.

El bloqueo de SQL permite establecer límites temporales, tales como:

• Restrinja la mayoría de los privilegios administrativos de los DBA al horario laboral. Puede limitar el acceso fuera de dicho horario a equipos, programas y tipos de actividad específicos.
• Restrinja el uso de herramientas de análisis y de inteligencia de negocios (BI) al horario laboral, dado que es poco probable que se requiera acceso de emergencia fuera de este.

Durante el horario laboral, el personal de seguridad y los administradores de bases de datos (DBA) están activos y supervisando los sistemas, lo que les permite reaccionar con rapidez ante cualquier actividad maliciosa. Asimismo, durante este periodo, es menos probable que los atacantes exploten un activo de comando y control (C2) que haya sido comprometido.

Fuera del horario laboral —cuando las organizaciones operan con equipos reducidos o personal de guardia— es precisamente cuando son más vulnerables. Si los sistemas informáticos permanecen encendidos mientras los expertos no están presentes, una alerta podría pasar desapercibida hasta el lunes por la mañana.

Mecanismos de Interrupción: Límites de Volumen y Exfiltración

Incluso si un atacante logra eludir las alertas de detección —por ejemplo, aprovechando una vulnerabilidad en una aplicación, como una inyección SQL o una vulnerabilidad de tipo BOLA—, sigue enfrentándose a una limitación física fundamental: la extracción de datos implica el movimiento de un volumen masivo de información.

Establecer umbrales estrictos para las consultas a la base de datos funciona como un mecanismo de interrupción automático:

Límites de extracción de filas: Si una cuenta de servicio de una aplicación lee habitualmente entre 500 y 1000 filas de datos confidenciales por minuto, con picos de 2000 filas por minuto, establecer un límite de 3000 filas por minuto restringirá de forma significativa la exfiltración masiva.

Esto significa que una única inyección SQL no podrá extraer más de 3000 filas. Asimismo, implica que incluso mediante múltiples consultas SQL (por ejemplo, en un ataque BOLA), se necesitarían más de 5 horas para extraer 1 millón de filas, y más de 2 días para extraer 10 millones de filas.

Límites en el volumen de llamadas: Restringir la frecuencia de las consultas al acceder a tablas que contienen datos confidenciales puede servir como un freno eficaz contra los ataques BOLA. Por ejemplo, es posible permitir extracciones mayores por minuto (por ejemplo, 10 000 filas), pero manteniendo una tasa de ejecución más baja (por ejemplo, 1000 llamadas por minuto).

Establecer límites por hora, en lugar de por minuto, permite un mejor promedio temporal. Esto posibilita picos más altos por minuto, manteniendo al mismo tiempo umbrales totales más bajos por hora.

Incluso si todas las alertas de detección fallan a la hora de notificar al personal de seguridad a tiempo, los mecanismos de limitación de tasa (rate-limiting) actúan como un cortafuegos que restringe la velocidad de la brecha, impidiendo que los atacantes extraigan una base de datos de clientes que contenga millones de registros. Esto limita el daño a una fracción del conjunto total de datos y proporciona al personal de seguridad un tiempo valioso para reaccionar.

Enmascaramiento Dinámico

El enmascaramiento dinámico de datos es, en cierto modo, el «pariente pobre» dentro del ámbito de la seguridad preventiva. Su objetivo es ofrecer información parcial de los campos a determinados usuarios; busca más bien cubrir una carencia funcional de la aplicación que actuar como una medida de seguridad propiamente dicha. Aunque a menudo se presenta como una solución milagrosa y fundamental, lo cierto es que, en las arquitecturas modernas, adolece de importantes limitaciones.

Dentro del motor de base de datos, el enmascaramiento dinámico solo tiene en cuenta el contexto de la base de datos (por ejemplo, el usuario de la base de datos o la dirección IP). Esto impide aplicar criterios de enmascaramiento granulares basados ​​en el usuario final que ha iniciado sesión en la aplicación web. De hecho, el caso de uso más habitual consiste en enmascarar solo una parte de la actividad de la aplicación.

Un enmascaramiento que realmente tenga en cuenta al usuario final —por ejemplo, ocultar números de seguridad social a los agentes de atención al cliente, pero mostrárselos a los analistas de crédito— debe realizarse en la capa de aplicación. Esto puede lograrse mediante el código de la propia aplicación o recurriendo a tecnologías como el «enmascaramiento dinámico a nivel de aplicación» (Application Dynamic Masking), que analizaremos más adelante en esta serie.

El enmascaramiento a nivel de base de datos resulta fundamental cuando se necesita enmascarar conexiones con privilegios. Si bien las conexiones sin privilegios suelen poder gestionarse mediante vistas, esto no es posible en el caso de las conexiones con privilegios. No obstante, dado que existen pocos escenarios en los que sea necesario enmascarar conexiones con privilegios, el enmascaramiento dinámico en el motor de base de datos aporta un valor limitado.

De la Teoría a la Práctica

Al implementar el bloqueo de sentencias SQL, existen dos requisitos innegociables:

1. Bloqueo al 100 %: El código SQL malicioso nunca debe ejecutarse.
2. Impacto mínimo en el rendimiento: La latencia y el rendimiento de la base de datos no deben verse comprometidos.

La mayoría de las soluciones tradicionales dependen de un servidor externo, por lo que fallan en uno de estos puntos. Esto significa que:

• Latencia: En una de las opciones de configuración, la base de datos se ve obligada a esperar a que el servidor central apruebe o rechace cada paquete antes de procesarlo. Esto genera una latencia inaceptable que ralentiza la base de datos.
• Acción diferida: En otra opción de configuración, la base de datos comienza a procesar todas las solicitudes de inmediato. Posteriormente, la conexión se interrumpe si el servidor central determina que el paquete debería haberse bloqueado. Esto implica que la actividad maliciosa llega a procesarse y, dependiendo del momento en que ocurra, es posible que incluso se devuelva el conjunto de resultados.

La arquitectura de Core Audit, por ejemplo, no depende de servidores externos para tomar decisiones de bloqueo. El agente que se ejecuta en el servidor de bases de datos toma decisiones instantáneas sobre cada ejecución. Esto garantiza que cada sentencia SQL sea revisada antes de su ejecución, manteniendo al mismo tiempo un impacto mínimo en el rendimiento de la base de datos.

Implementación Segura

Bloquear consultas en un entorno de producción real conlleva riesgos. Una política mal configurada o una actividad no prevista pueden provocar graves problemas: pueden inutilizar una aplicación, impedir que los usuarios legítimos realicen sus tareas o, incluso, causar la corrupción de los datos.

Antes de activar una política de bloqueo, considere esta metodología de implementación de 4 pasos:

Paso 1: Validación histórica

Nunca active una regla de bloqueo a ciegas. Utilice el análisis forense proactivo de Core Audit para revisar la actividad en el repositorio de seguridad. Analice un periodo de al menos 90 días hacia atrás para asegurarse de que no se haya realizado ninguna actividad que pudiera activar la regla de bloqueo. Lo ideal es establecer el intervalo de tiempo desde el inicio de su historial, a fin de validar que ningún proceso empresarial legítimo, tarea en segundo plano o flujo de trabajo de una aplicación infrinja la regla que pretende aplicar.

Paso 2: Prueba

Implementa la regla en un entorno de prueba o de preproducción. Ejecuta pruebas de regresión exhaustivas en los flujos de trabajo legítimos de la aplicación para garantizar que no se produzcan falsos positivos. A continuación, simula el ataque que pretendes bloquear y confirma que la regla funciona según lo previsto.

Paso 3: Modo de solo registro

Implementa la política en el entorno de producción en modo de solo registro. El agente Core Audit realizará todas sus funciones habituales, tal como lo haría durante un bloqueo real; sin embargo, en lugar de ejecutar el bloqueo, generará un evento de tipo «bloqueo potencial» (WOULD BLOCK). Mantén la política en este modo de solo registro durante un tiempo para asegurarte de que no surjan imprevistos.

Paso 4: Aplicación activa

Una vez que las pruebas den luz verde, activa la regla para que entre en vigor.

Regla operativa: Asegúrate siempre de que los administradores de bases de datos (DBA) y el personal de seguridad que están de guardia cuenten con un procedimiento claro y sepan cómo desactivar el bloqueo en caso de emergencia. Existen varias formas de hacerlo: desde cambiar la política al modo de solo registro (log-only) hasta desactivar la política en la instancia o desconectar por completo el agente. Sin embargo, ante cualquier incidencia a las 4 de la madrugada, el personal debe saber cómo restablecer el funcionamiento del sistema.

Reflexión Final

El bloqueo de SQL puede suponer un riesgo operativo. Sin embargo, mediante políticas deterministas y fiables, junto con una implementación estructurada por fases, es posible minimizar este riesgo y convertir el bloqueo en una herramienta que refuerce la seguridad de manera responsable desde el punto de vista operativo.

No obstante, no debería ser el primer paso en una estrategia avanzada de seguridad de bases de datos. El bloqueo de SQL es una medida de seguridad potente, pero solo debe adoptarse cuando se dispone de una visibilidad completa y un control sólido sobre las bases de datos.

El bloqueo de SQL no debe implementarse por el simple hecho de hacerlo. Es necesario contar con una metodología clara —como la descrita en este artículo— y comprender a fondo cómo esta medida mejorará la seguridad y contribuirá a la postura de seguridad general. De lo contrario, se convertirá en una iniciativa aislada más, sumada a un conjunto inconexo de medidas de seguridad dispersas.

Si esta serie ha dejado algo claro, es lo siguiente: una seguridad eficaz se basa en una detección profunda, potenciada por mecanismos de prevención avanzados. Combinar las metodologías de detección analizadas anteriormente con medidas de prevención da lugar a una defensa sumamente sólida y potente, prácticamente impenetrable. Al superponer distintas medidas y abordar cada vector de ataque desde múltiples ángulos, se maximizan las probabilidades de detectar un ataque y responder a él en tiempo real.

¿Qué Sigue?

Hasta ahora, esta serie se ha centrado exclusivamente en la seguridad de la capa de base de datos. Sin embargo, como ya hemos señalado, la base de datos es solo el primer frente. En las arquitecturas modernas de tres niveles (3-tier), la capa de aplicación se sitúa justo encima de la base de datos. Algunos ataques que logran atravesar la capa de aplicación son visibles en la base de datos, pero otros no. Las identidades de los usuarios finales, el contexto y la lógica de negocio residen en el ámbito de la aplicación; por tanto, para protegerlos, es necesario analizar el entorno desde la perspectiva de la propia aplicación.

En la sexta parte, centraremos nuestra atención en la Seguridad de Aplicaciones, explorando cómo obtener, en este nivel, el mismo grado de control que logramos en la base de datos.