La industria de la seguridad tiene la costumbre de intentar encajar piezas cuadradas en agujeros redondos. Uno de los ejemplos más recurrentes es el intento de proteger las bases de datos mediante tecnología centrada en la red. Se les denomina «cortafuegos de bases de datos» o sistemas de «monitorización de la actividad de bases de datos (DAM)» basados ​​en la inspección de paquetes, pero estas denominaciones ocultan un error fundamental: una base de datos es un motor de ejecución, no un canal de comunicación. Si se intenta protegerla mediante la monitorización de paquetes, se está construyendo una mosquitera, no un muro de hormigón.

El Problema de los Protocolos con Estado

Los protocolos de bases de datos (por ejemplo, Oracle SQLNet, Microsoft TDS) no son estáticos. A diferencia de HTTP, donde una solicitud es en gran medida autónoma, las conversaciones en las bases de datos tienen estado.

Representación dinámica de datos: El protocolo de la base de datos y su codificación se negocian al establecer la conexión, pero pueden cambiar durante la sesión. Diversos factores pueden provocar que el cliente y el servidor renegocien la forma en que, por ejemplo, se representan los números. Cada paquete subsiguiente debe interpretarse a través de esta nueva perspectiva.

La fragilidad del analizador de red: Si un monitor de red no detecta un segmento TCP debido a la congestión o la alta carga de la red, pierde el estado de la conversación. Ya no puede decodificar de forma fiable los paquetes siguientes, lo que genera vulnerabilidades que permiten que el SQL malicioso pase desapercibido.

El Desafío del Cifrado

El cifrado supone el fin de la inspección de paquetes.

Iniciación del lado del cliente: Con las configuraciones predeterminadas de las bases de datos, los clientes pueden actualizar unilateralmente a una conexión TLS para proteger la sesión, lo que inhabilita instantáneamente cualquier analizador de red.

La dificultad del descifrado: Para inspeccionar este tráfico, una herramienta de red debe actuar como intermediario, lo que a menudo requiere las claves privadas de cada servidor de base de datos. Esto genera un enorme riesgo de seguridad.

Invisibilidad local: Cuando un usuario se conecta localmente mediante un socket, una tubería o memoria compartida, no hay paquetes de red que interceptar. Para solucionar esto, las herramientas de red implementan agentes host invasivos para interceptar los canales de comunicación del sistema operativo local y enviar el tráfico al dispositivo. Sin embargo, si esas conexiones locales están cifradas, el agente host queda completamente inaccesible. Ejecutar un proxy de descifrado dentro del kernel de un servidor de base de datos provocaría una grave inestabilidad del sistema. Por lo tanto, el tráfico cifrado local sigue siendo un punto ciego permanente para las herramientas centradas en la red.

Riesgo en línea: Para inspeccionar el tráfico cifrado, la herramienta ya no puede funcionar como un analizador pasivo. Debe convertirse en un proxy inverso inyectado directamente en la conversación. Esto transforma la herramienta de un observador pasivo a un punto único de fallo para los datos de producción, lo que introduce latencia y riesgo operativo.

El truco de «enganche de binarios»: Algunas herramientas de red antiguas, al darse cuenta de que el cifrado rompe su modelo, intentan sobrevivir implementando interceptores a nivel de aplicación. Estos agentes vuelven a enlazar los binarios compilados de la base de datos para capturar el tráfico justo después del descifrado. Si bien esto elude TLS, introduce una fricción operativa considerable (modificaciones de binarios, reinicios de la base de datos y una elevada sobrecarga de mantenimiento durante las actualizaciones de la base de datos). Más importante aún, hereda todas las demás deficiencias estructurales de un monitor de red, incluidos los puntos ciegos del código.

Puntos Ciegos del Código

El monitor de red asume que una base de datos solo recibe cadenas SQL simples y devuelve datos. En realidad, las bases de datos modernas son entornos de ejecución avanzados que ejecutan código complejo lejos de la tarjeta de red.

Consideremos un escenario en el que un atacante utiliza el comando EXECUTE IMMEDIATE con una cadena concatenada. La herramienta de red ve una cadena de texto inofensiva u ofuscada en la red. Sin embargo, el motor de captura espera hasta que la base de datos ensambla el comando y está a punto de ejecutarlo, exponiendo la intención maliciosa en texto plano (por ejemplo, CREATE USER HACKER) justo antes de la ejecución.

Las bases de datos tienen muchas capacidades de ejecución de código, lo que amplía y profundiza aún más este punto ciego. He aquí algunos ejemplos:

• Ejecución ad-hoc: La mayoría de los motores de bases de datos permiten enviar bloques de código anónimos para su ejecución inmediata. No dejan rastro en el esquema y no requieren privilegios especiales para ejecutarse.
• Procedimientos almacenados y disparadores: Un simple comando de red, aparentemente inofensivo, puede desencadenar un script interno masivo y malicioso ya almacenado en el servidor. Los disparadores, en particular, pueden activarse mediante cualquier operación DML aparentemente inocua.
• Tareas programadas: El servidor de bases de datos puede ejecutar un script malicioso en nombre de un atacante incluso cuando no hay ningún usuario conectado a la base de datos.
• Entornos de ejecución integrados: Los motores empresariales llevan esta arquitectura de código mucho más allá al integrar máquinas virtuales completas directamente en la base de datos. Por ejemplo, la JVM de Oracle o el entorno de ejecución .NET de SQL Server. Los atacantes pueden ejecutar aplicaciones Java o .NET completas dentro del motor de la base de datos, totalmente ocultas a la tarjeta de red.

Historia de Fracasos con Reutilización

Si la inspección de paquetes es tan fundamentalmente defectuosa para la seguridad, ¿por qué está tan extendida? Por un accidente histórico.

Hace veinticinco años, la única opción era la auditoría nativa. Proporcionaba la verdad, pero conllevaba una sobrecarga de rendimiento desmesurada que «destruía» los entornos de producción. Al mismo tiempo, las empresas desarrollaban la inspección de paquetes para la monitorización del rendimiento. Querían medir la duración de las consultas observándolas en la red.

Esa tecnología de monitorización del rendimiento acabó siendo superada por un método superior: el rastreo de memoria compartida. Sin mercado para esta tecnología, estos proveedores se volcaron en la incipiente fiebre del oro del cumplimiento normativo desencadenada por la Ley Sarbanes-Oxley (SOX).

Rebautizar una herramienta de rendimiento fallida como solución de seguridad no se hizo para atrapar hackers, sino para cumplir con los requisitos de los auditores.

La Solución: Captura del Motor SQL

La seguridad real requiere dejar de lado la comunicación por cable y centrarse en el motor.

La única forma de saber con certeza qué hace una base de datos, sin la pérdida de rendimiento que suponía la auditoría nativa de los años 90, es acceder directamente al motor SQL. En lugar de intentar reconstruir la realidad, es necesario utilizar un oyente basado en eventos que la observe.

La captura a nivel del motor registra la actividad después de que la base de datos haya descifrado el paquete, tras analizar el protocolo y en el preciso instante en que el motor está a punto de ejecutarlo. Al capturar la ejecución real de SQL, se obtiene la información definitiva sobre lo que el motor está a punto de ejecutar.

Además, elimina la sobrecarga de procesamiento al evitar esfuerzos duplicados. Dado que el motor de la base de datos ya se ha encargado del descifrado y el análisis del protocolo, la captura registra la actividad completa. No se requiere procesamiento adicional de la CPU ni el envío de grandes cantidades de datos a través de la red.

• Sin puntos ciegos: Detecta conexiones locales, sesiones cifradas y procedimientos internos, ya que captura la actividad en el momento de su ejecución.
• Impacto mínimo: Bajo consumo de CPU (normalmente inferior al 3 %), bajo ancho de banda de red (normalmente unos pocos megabytes) y latencia cero. Está diseñado para entornos de producción de altísimo rendimiento.

Al trasladar el límite de seguridad del perímetro de la red a la capa de ejecución, las organizaciones pueden lograr auditorías continuas y de alta resolución, independientemente de cómo se haya iniciado la conexión.

Inspección de Paquetes Vs. Captura Mediante Motor SQL

La diferencia fundamental entre estas dos arquitecturas radica en dónde se capturan los datos:

Conclusión: Supera la «Cortina de Seguridad» (Firewall)

Es hora de abandonar la metáfora de la «cortina de seguridad» para las bases de datos. Una base de datos no es una red. Es un entorno complejo que gestiona datos, los analiza y ejecuta código. Monitorizar los paquetes para proteger una base de datos solo proporciona una falsa sensación de seguridad. Cuando se produce una brecha real, confiar en un analizador de paquetes es como intentar ver un partido de fútbol observando a los jugadores entrar al campo. Sabes quién entró, pero no tienes ni idea de lo que pasó en el partido.

Para proteger el núcleo de tus datos, debes usar herramientas que comprendan el motor de la base de datos y que estén presentes en el juego, no solo observando desde fuera.