Esta es la segunda parte de nuestra serie sobre cómo proteger sus datos. En la primera parte, establecimos los fundamentos teóricos y la necesidad de equilibrar y priorizar la detección sobre la prevención. En esta entrega, pasamos a la implementación práctica, comenzando con el control de sesiones de la base de datos.

El control de sesiones suele ser más sencillo, pero es necesario aprender a caminar antes de correr. Lograr una visibilidad básica de las sesiones es fundamental antes de proteger patrones de actividad más complejos dentro de ellas.

El control de sesiones es relativamente simple, accesible y fácil de entender, pero limitado en lo que puede abarcar. Sin embargo, a pesar de su simplicidad, la mayoría de las organizaciones no lo implementan correctamente. Generan millones de registros de conexión en informes o en un SIEM, nunca los revisan y asumen que ya implementan la «seguridad de sesiones». Esto es un cementerio de informes, no una seguridad práctica.

Comenzamos aquí por tres razones:

1. Tiene valor en materia de seguridad: si bien este valor es limitado, el control de sesión puede detectar ciertos ataques. En particular, el robo de credenciales y el uso indebido de la cuenta de la aplicación. En esos casos, la fuente de la actividad tiende a cambiar, lo que proporciona una alerta temprana antes de que se modifique o robe cualquier dato.
2. Es el primer paso hacia la visibilidad: el control de sesiones le brinda la información más básica sobre quién accede a su base de datos, desde dónde y con qué herramientas. La mayoría de las organizaciones no pueden responder estas preguntas básicas, y sin estas respuestas, no puede planificar sus controles de seguridad ni segmentarlos de manera efectiva.
3. Es el campo de pruebas ideal para metodologías: aplicar conceptos como informes diarios, alertas declarativas, detección de anomalías, análisis forense proactivo y bloqueo es mucho más fácil de implementar en eventos de conexión simples (inicios de sesión, direcciones IP, nombres de programas) antes de intentar aplicarlos a miles de millones de consultas SQL.

El control de sesiones no es la solución definitiva; es el primer paso. Después vienen los pasos 2, 3 y 4. Pero no deberías saltarte este paso.

Lo Que Le Falta al Control de Sesiones

Seamos completamente transparentes sobre lo que el control de sesiones puede y no puede hacer. En muchos casos, el control de sesiones no será la solución definitiva:

• No detecta la mayoría de los ataques: desde el abuso de privilegios o la actividad de comando y control (C2) hasta ataques complejos a aplicaciones, si el atacante es un usuario real o lo suplanta lo suficientemente bien, el control de sesión no lo detectará.
• Metadatos no verificados proporcionados por el cliente: Al establecer una conexión, el cliente envía información como el nombre del programa, el usuario del sistema operativo y la terminal. El servidor de la base de datos no puede verificar esta información. Un atacante sofisticado puede falsificarla.
• Información poco fiable: El nombre de usuario es fiable porque el servidor de la base de datos lo autenticó, y la dirección IP tiene cierta relevancia, ya que falsificarla es más complejo. Sin embargo, los metadatos que proporciona el cliente, como el nombre del programa y el usuario del sistema operativo, son texto del lado del cliente que puede ser manipulado.

Cuando vayamos más allá del control de sesiones, analizaremos cómo detectar ataques más sofisticados sin depender de los datos proporcionados por el cliente. Sin embargo, detectar ataques comunes y sencillos en la capa de sesión representa una gran ventaja.

Explorando Las Metodologías

Para que el control de sesiones sea útil, necesitamos una forma de convertir los datos de conexión sin procesar en información de seguridad procesable. Esto lo logramos mediante seis mecanismos distintos: análisis forense reactivo, análisis forense proactivo, informes, alertas, anomalías y bloqueo.

Análisis Forense Reactivo: La Autopsia

El análisis forense reactivo se produce después de un incidente de seguridad y cuando es necesario investigarlo. Este es el significado tradicional del análisis forense: se activa una alerta, se notifica una brecha de seguridad o un auditor formula una pregunta sencilla como «¿Quién inició sesión en la base de datos el martes a las 3:00 a. m.?«. Es una herramienta de investigación indispensable para reconstruir la cronología de un incidente.

Al considerar una investigación posterior al incidente, la principal preocupación es: «¿Tendremos los datos necesarios cuando llegue el momento?». Con los datos de sesión, es totalmente posible conservar todas las sesiones para que no falte nada. También es recomendable realizar investigaciones rutinarias para garantizar la disponibilidad de los datos y que el equipo sepa cómo consultarlos.

Sin embargo, si el análisis forense reactivo es el único uso operativo de los datos de sesión, se está operando exclusivamente en una postura reactiva de respuesta a brechas de seguridad.

Análisis Forense Proactivo: Mayor Visibilidad

Si bien ambos métodos forenses utilizan registros históricos de sesiones, sus objetivos son completamente opuestos: Analizar el pasado frente a Prospectiva. El análisis forense proactivo es una herramienta exploratoria que se utiliza como parte de las operaciones de seguridad habituales. Responde a preguntas operativas fundamentales como:

• ¿Quién se conecta a esta base de datos en un día laborable normal?
• ¿Qué aplicaciones cliente originan estas conexiones?
• ¿Existen conexiones locales inesperadas ejecutándose internamente desde el servidor de la base de datos?
• ¿Comparten varios operadores una única cuenta con privilegios?

No se puede crear una alerta para un comportamiento anómalo si no se sabe cómo es un comportamiento normal. El análisis forense proactivo proporciona la visibilidad básica necesaria para identificar a los actores clave en su sistema. Es la primera herramienta que se utiliza para comprender el entorno y planificar los controles de seguridad. Sin esta visibilidad, los controles de seguridad son como disparar a ciegas: es poco probable detectar a un intruso.

El análisis forense proactivo también expone malas prácticas de seguridad. Detecta rápidamente hábitos peligrosos, como que los administradores de bases de datos se conecten mediante utilidades de terceros no autorizadas, que las cuentas se conecten desde varias máquinas o que las cuentas de servicio antiguas inicien sesión desde subredes obsoletas.

Cuando se realiza periódicamente, el análisis forense proactivo garantiza que siempre esté al tanto de lo que sucede en su base de datos y de si los nuevos comportamientos justifican la actualización de sus controles de seguridad.

Informes Eficaces

La mayoría de los informes de seguridad de bases de datos fallan porque intentan ser exhaustivos en lugar de informativos.

Si su estrategia de informes de sesión consiste en enviar por correo electrónico un PDF de 50 000 líneas con todos los eventos de conexión de las últimas 24 horas a la bandeja de entrada de un analista del SOC, no tiene informes, sino correo basura. Ese informe será ignorado, archivado automáticamente o eliminado de inmediato. No cumple ninguna función de seguridad, solo es un desperdicio de recursos.

Un informe de sesión eficaz ofrece un vistazo diario de 30 segundos para que un operador humano pueda detectar un problema o un cambio a nivel macro que requiera acción. Por ejemplo:

• Programas Cliente Distintos: Una lista resumida de todos los usuarios y nombres de programas únicos detectados en las últimas 24 horas. Si MSACCESS.EXE aparece repentinamente en la lista, se tarda 2 segundos en detectar la anomalía.
• Cuentas Privilegiadas: Un resumen consolidado de los puntos de inicio de sesión de las cuentas de DBA desde ayer (usuario de DBA, programa, IP de origen, número de inicios de sesión). Será evidente de inmediato si un DBA se conecta desde una subred sospechosa, utiliza un programa inusual o inicia sesión un número excesivo de veces.
• Cuenta de Aplicación: Un informe de los programas e IP que utilizan la cuenta de aplicación. Si una cuenta de aplicación fue utilizada por un programa diferente o una dirección IP adicional, esa línea extra en el informe destaca de inmediato.

Los informes no pueden detectar ataques en tiempo real: ese es el trabajo de las alertas. Los informes existen para garantizar que usted esté al tanto de lo que sucede en sus bases de datos, mantenga una higiene ambiental básica y garantice que su base operativa no se haya desviado silenciosamente con el tiempo.

Alertas Declarativas

Mientras que los informes te dicen lo que pasó ayer, las alertas existen para informarte de lo que está sucediendo ahora mismo. El objetivo principal de las alertas declarativas es la detección inmediata, lo que permite a tu equipo responder antes de que se produzca una filtración de datos o un daño mayor.

Las alertas se basan en la idea de informar exclusivamente sobre eventos que no deberían ocurrir. A diferencia de los informes diarios, las alertas solo consumen tiempo del analista cuando se activan. Esto significa que puedes gestionar muchas más alertas que informes.

Para crear alertas declarativas eficaces, debes definir explícitamente qué se considera «malo». Esto puede ser una lista negra que defina comportamientos malos conocidos o una lista blanca que defina comportamientos buenos aprobados, convirtiendo todo lo demás en «malo». En el contexto del control de sesiones, creas reglas estrictas basadas en combinaciones de metadatos de conexión.

• Usuarios privilegiados: Se generará una alerta si una cuenta de administrador de base de datos se conecta mediante un método distinto a SQL*Plus o Management Studio, o si una cuenta privilegiada inicia sesión desde una estación de trabajo fuera de la subred de administración.
• Cuentas de aplicación: Se generará una alerta si una cuenta de aplicación inicia una sesión desde una dirección IP que no corresponde a un servidor de aplicaciones designado, o si se origina desde un programa no autorizado.
• Anomalías de red: Se generará una alerta sobre conexiones directas a la base de datos que se originen desde subredes inesperadas, como grupos de VPN, redes externas o subredes internas que nunca deberían acceder directamente a la interfaz de la base de datos.

A diferencia de los informes diarios, las alertas declarativas se adaptan excepcionalmente bien porque permanecen inactivas hasta que se activan. Puede definir 50 reglas declarativas distintas en todo su entorno. Siempre que estén estrictamente definidas para corregir infracciones de políticas, rara vez se activarán; es decir, cuando una se active, requerirá una investigación inmediata.

Análisis de Anomalías

Las alertas declarativas requieren conocer las condiciones exactas que se desean aplicar. Pero, ¿qué ocurre con los cambios impredecibles o demasiado complejos para codificarlos manualmente? Por ejemplo, activar una alerta cuando un usuario se conecta desde una nueva IP requeriría crear una regla manual para cada usuario y su IP actual, un enfoque poco práctico.

Aquí es donde entra en juego la detección de anomalías. En lugar de definir una regla estática («Alerta si el usuario X se conecta desde una IP distinta de Y»), los motores de detección de anomalías rastrean los cambios en los perfiles de actividad a lo largo del tiempo (por ejemplo, «Alerta cuando un usuario se conecta desde una IP que no ha utilizado en los últimos 3 meses»). Esto puede abarcar múltiples dimensiones, filtros y parámetros de comparación («Alerta cuando el usuario X utiliza una combinación inusual de programas e IPs a una hora inusual del día»).

Comparación de los dos enfoques:

	Alerta Declarativa	Detección de Anomalías
Tipo de Regla	Reglas explícitas y estáticas	Dinámica, conductual
Ejemplo de Regla	Si el programa es SQLPLUS.EXE	Si la usuario de DB utiliza un NUEVO programa
Tipo de Infracción	Incendios cuando se infringe una política.	Se activa cuando cambia un comportamiento.
Falsos Positivos	Predecible, más sencillo de ajustar	Ruido potencial, más difícil de ajustar
Cobertura de Ataque	Es más difícil atrapar un ataque real.	Es más fácil atacar objetivos desconocidos.

Cómo las Anomalías Mejoran la Seguridad

Más allá de la flexibilidad de comportamiento, la detección de anomalías ofrece dos ventajas clave:

• Escala masiva: el motor de anomalías automatizado procesa volúmenes de actividad que ningún analista humano podría auditar manualmente.
• Cambios sutiles: resalta pequeñas diferencias que los ojos humanos fácilmente pasan por alto.

Por ejemplo:

• Un administrador de bases de datos que inició sesión desde las mismas tres direcciones IP durante seis meses se conecta desde una cuarta dirección IP desconocida.
• Una cuenta de aplicación utilizada por diferentes programas en varios servidores recibe una conexión de un servidor válido, pero con la aplicación incorrecta para ese servidor.
• En una base de datos con 2000 usuarios en 2000 estaciones de trabajo, una estación de trabajo es utilizada repentinamente por dos cuentas diferentes, o una sola cuenta se conecta desde múltiples puntos finales.

El Escollo de la Detección de Anomalías

Las anomalías son una herramienta poderosa, pero tienen una falla evidente: las máquinas no aplican el juicio humano.

Si un administrador de bases de datos cambia legítimamente la IP de su estación de trabajo y se conecta desde ella todos los días, un motor de detección de anomalías generará una alerta el primer día, pero eventualmente aceptará el nuevo comportamiento como la «nueva normalidad». Si esa nueva IP resulta ser un punto final comprometido perteneciente a un asistente administrativo, el motor de detección de anomalías lo ignorará una vez que el nuevo comportamiento forme parte de la base.

Por eso, la detección de anomalías no puede funcionar de forma aislada. Debe combinarse con análisis forenses proactivos e informes para que los operadores humanos validen periódicamente si los cambios de comportamiento son legítimos.

Bloqueo

El bloqueo de actividad es la evolución natural de las alertas: en lugar de enviar una alerta cuando se infringe una política, la solución puede bloquear la sesión en tiempo real.

En el control de sesiones, el bloqueo se basa en la inclusión en listas negras o blancas estrictas de rutas de conexión específicas. Por ejemplo, se pueden bloquear conexiones según subredes, usuarios de bases de datos, programas cliente o una combinación de los tres.

La Realidad Práctica del Bloqueo

Si bien el bloqueo en línea ofrece protección activa contra el acceso no autorizado, también conlleva el riesgo de un tiempo de inactividad autoinfligido.

En un entorno de producción, un falso positivo en una regla de bloqueo no solo genera un ticket: desactiva aplicaciones, detiene procesos comerciales y activa llamadas de emergencia al servicio de asistencia técnica. Si un ingeniero de redes reconfigura un clúster de servidores de aplicaciones para usar un nuevo rango de IP sin actualizar su motor de bloqueo, su control de seguridad simplemente provocó una interrupción autoinfligida.

Para el control de la sesión, el bloqueo en línea debe aplicarse de forma conservadora:

1. Lista blanca estricta para cuentas de servicio: Exija que las cuentas de servicio de la aplicación principal solo puedan conectarse desde servidores y programas de aplicación definidos explícitamente, bloqueando todo lo demás.
2. Lista blanca para herramientas de cliente aprobadas: Restrinja el acceso a los programas aprobados. Por ejemplo, los administradores de bases de datos pueden usar SQL*Plus o Toad, mientras que el resto de usuarios solo pueden usar el cliente de la aplicación (p. ej., cliente Java o cliente SQL .NET). Los inicios de sesión directos en la base de datos desde herramientas obsoletas o peligrosas como MSACCESS.EXE se bloquean inmediatamente.
3. Validación con alerta previa: Ejecute las nuevas reglas de bloqueo en modo «solo registro» durante varias semanas para observar el tráfico y evaluar el riesgo de falsos positivos antes de activar la aplicación activa.

El control de sesiones proporciona una protección básica superficial. Detiene a los atacantes obvios y detecta el robo de credenciales rudimentario. Sin embargo, no puede detener a un atacante que se hace pasar por un usuario legítimo. Para ello, es necesario ir más allá de la interfaz de sesión y controlar la actividad SQL real, tema que abordaremos en las partes 3 y 4.

De la Teoría a la Práctica: La Realidad de la Implementación

Conociendo los mecanismos teóricos que sustentan el control de actividad, nos enfrentamos al reto de implementar esta teoría en la práctica. Si bien el control de sesiones es más sencillo que el control SQL, aún presenta los mismos dos desafíos fundamentales:

• Captura de datos: Recopilar información sobre todas las sesiones puede ser complejo. Las conexiones directas pueden provenir de diversas fuentes, tanto remotas como locales. Muchas sesiones están cifradas con TLS, y algunas tecnologías basadas en paquetes tienen dificultades para monitorizarlas. Con patrones de diseño modernos como «conexión por solicitud» o «conexión por transacción», el número de sesiones puede alcanzar decenas de millones al día. Recopilar toda esta información sin afectar el rendimiento de la base de datos y sin omitir ningún dato puede resultar complicado.
• Procesamiento de datos: Convertir todos estos datos brutos en información útil y relevante requiere la aplicación a gran escala de todas las metodologías mencionadas. Si bien algunas soluciones funcionan razonablemente bien en ciertos aspectos, es muy raro que lo abarquen todo.

Para comprender cómo funcionan estos seis mecanismos en un entorno de producción real, analicemos los requisitos arquitectónicos necesarios para su ejecución a gran escala, utilizando nuestra plataforma, Core Audit, como ejemplo.

Captura Completa de Datos e Impacto en el Rendimiento

Las capacidades de captura de Core Audit son únicas, ya que recopilan datos directamente del motor de la base de datos. Otras soluciones suelen depender de la auditoría nativa de la base de datos (lo que genera problemas de rendimiento) o de la captura de paquetes (lo que genera problemas de visibilidad). Considere estas limitaciones:

• Conexiones cifradas: Las tecnologías de captura de paquetes a menudo no inspeccionan los intercambios de sesiones cifradas. Core Audit captura el contexto directamente del motor de la base de datos, siendo completamente inmune al cifrado TLS.
• Conexiones de servidor local: Las rutas de conexión locales (por ejemplo, memoria compartida, sockets de dominio o conexiones de bucle invertido) evitan las interfaces de red estándar y, como es bien sabido, las herramientas de monitorización de red no las detectan.
• Impacto en el rendimiento: Las soluciones que dependen de la auditoría nativa de la base de datos degradan gravemente el rendimiento, y las técnicas de captura de paquetes locales envían un tráfico de red masivo fuera del host. Core Audit evita ambos problemas, operando con un impacto mínimo en el rendimiento (menos del 3 % de sobrecarga) y requiriendo un ancho de banda de red mínimo.

Transformando Datos Brutos en Información Útil

Hemos analizado en profundidad el principal desafío en el control de sesiones: convertir los datos brutos en controles operativos eficaces. Repasemos estos mecanismos y comparemos su funcionamiento en una implementación deficiente con el de una implementación adecuada (como Core Audit):

Mecanismo	Mala Implementación	Solución Moderna (Diseño de Core Audit)
Análisis Forense Reactivo (conservación de pruebas)	Repositorio en el servidor, espacio de almacenamiento significativo o grabación parcial (no todas las sesiones).	Registra cada sesión en un repositorio externo inmutable, eficiente e histórico. Así, por ejemplo, sabrá quién se conectó hace 6 semanas a las 3 de la madrugada.
Forense Proactiva (ganar visibilidad)	Una larga lista de todas las sesiones sin visualización interactiva para facilitar la comprensión de la información.	Visualice los «jugadores» activos de la base de datos mediante vistas de lista interactivas, árboles, diagramas de Sankey, gráficos circulares, gráficos de red y mucho más.
Informes Eficaces (para mantenerte informado)	Informes extensos que el personal no puede leer. Falta de personalización. Soluciones de informes externas. Una casilla de verificación de cumplimiento que no aporta valor en materia de seguridad.	Motor de informes integrado para sintetizar millones de eventos de conexión en resúmenes diarios, semanales o mensuales sencillos. Se envían automáticamente a través de archivos, correo electrónico, Syslog o acciones personalizadas.
Alertas (Declarativas y de Anomalías) (notificación en tiempo real)	Demasiadas alertas o muy pocas (falsos negativos). No cubre todos los vectores de ataque. Falta de detalles sobre lo sucedido. No hay opciones de configuración.	Alertas estáticas (p. ej., un inicio de sesión fallido del administrador de la base de datos) junto con anomalías de comportamiento dinámicas (p. ej., un usuario que se conecta desde un nuevo programa o dirección IP). Las alertas son una extensión de los informes, personalizables y configurables.
Bloqueo (prevención activa)	Introduce latencia. Permite que la actividad maliciosa pase y luego cierra la sesión. No hay ningún mecanismo para evitar falsos positivos.	Motor de bloqueo en tiempo real que puede probar en modo «Solo registro». Bloquee las conexiones según el origen de la actividad, garantizando que tanto la aplicación como los administradores de bases de datos se conecten desde programas y subredes autorizados.

Primero lo Básico

El control de sesiones no es la solución definitiva para la seguridad de bases de datos. No puede detener la mayoría de los ataques ni reemplaza el control de actividad SQL, que es más avanzado.

Sin embargo, ignorar el control de sesiones por considerarlo infalible es un error operativo fundamental. El control de sesiones proporciona los puntos de referencia básicos para detectar ataques cuando cambia el origen de la actividad. Además, ayuda a comprender mejor el entorno en el que se opera. Finalmente, sirve como el entorno de pruebas definitivo para dominar el análisis forense, la generación de informes, las alertas, la detección de anomalías y el bloqueo.

Una vez que se ha establecido un control estricto sobre quién accede a la base de datos, se está listo para evaluar qué hacen realmente esas sesiones dentro de ella.

En la Parte 3, vamos más allá de la conexión para explorar el control de actividad SQL para el acceso a datos confidenciales.