La industria de la ciberseguridad se basa en un cúmulo de mentiras.

Cada año, los equipos de seguridad empresarial invierten millones en firewalls de última generación, acceso a redes de confianza cero y proveedores de protección perimetral que prometen convertir su infraestructura en una fortaleza impenetrable. Cada año, surge una nueva promesa sobre la próxima revelación. Y cada año, esas mismas empresas terminan en los titulares tras un catastrófico incidente de filtración de datos.

Los proveedores culpan a «actores estatales sofisticados» o a «errores del usuario». El verdadero culpable es la ilusión arquitectónica.

Hemos pasado décadas obsesionados con los perímetros de red, los puntos finales y la gestión de acceso e identidad, tratando los datos en sí mismos como algo secundario que se puede proteger con unas pocas casillas de verificación de cumplimiento y cifrado básico.

Esta serie de artículos es un plan pragmático y brutalmente honesto para la implementación práctica de una filosofía diferente: la seguridad centrada en los datos.

Si está cansado de la palabrería corporativa, las listas de verificación de cumplimiento y la sensación de impotencia ante las amenazas interminables, esta serie de artículos es para usted. Abordaremos la cruda realidad de implementar una seguridad estricta en entornos de producción empresariales de alto rendimiento.

Sin tecnicismos. Solo arquitectura, ingeniería y la dura realidad de proteger datos reales.

Bienvenidos a la Parte 1, donde explicamos los fundamentos teóricos necesarios para los pasos prácticos del resto de la serie.

El Perímetro Poroso y la Seguridad Centrada en los Datos

Si su estrategia de seguridad de datos se basa en mantener a los ciberdelincuentes fuera de su red, ya ha perdido.

No importa cuánto presupuesto haya invertido en firewalls de última generación, proveedores de identidad o detección de endpoints. La cruda realidad de las empresas modernas es que no se puede prevenir la intrusión. El perímetro es vulnerable porque la actividad empresarial exige conectividad. Un solo correo electrónico de phishing bien elaborado, una actualización no aplicada a una aplicación externa poco conocida o una pequeña configuración incorrecta en un servidor de correo son suficientes.

Peor aún, la amenaza podría estar ya dentro de su edificio, con una credencial válida, iniciando sesión con un nombre de usuario y contraseña corporativos legítimos. Hay demasiados empleados, consultores, contratistas y otras personas que se mueven libremente por la red corporativa.

Las estrategias de seguridad que se centran exclusivamente en las barreras externas parten de dos premisas falsas: que las barreras son sólidas y que todos los que están dentro están a salvo.

Aquí es donde comienza la seguridad centrada en los datos. Es reconocer desde el punto de vista arquitectónico que las barreras externas fallarán, o que ya han fallado. Cuando se vulnera el perímetro, su estrategia de seguridad debe reorientarse por completo para proteger los datos. Esto incluye las capas de aplicación y base de datos.

La seguridad centrada en los datos no consiste en impedir la entrada de alguien al edificio, sino en construir fortificaciones internas e impenetrables que protejan directamente los datos desde dentro hacia fuera, partiendo de la base de que el atacante ya se encuentra en la sala.

Controles de Producción

En entornos que no son de producción, la protección de datos puede ser estática: se enmascara, tokeniza o codifica el conjunto de datos, ya que los ingenieros no necesitan valores reales para probar el código. Una vez enmascarados, el riesgo desaparece.

En producción, no se pueden ocultar ni modificar los datos. La aplicación y sus usuarios necesitan acceso a los datos reales para procesar transacciones y operar el negocio. La seguridad en producción no puede consistir en bloquear el acceso a los datos al sistema, sino en controlar la actividad que accede a ellos.

¿Por qué fallan los controles de cifrado?

Una base de datos requiere todos sus archivos para iniciarse. Las filtraciones de datos no ocurren porque los atacantes roben todos los discos duros físicos con todos los archivos del centro de datos. Tampoco copian todos los archivos de la base de datos para almacenarlos en su propio hardware replicado. En las filtraciones de datos, los atacantes extraen la información aprovechando el hardware y la base de datos, explotando las vías de acceso legítimas integradas en la arquitectura.

Control de Seguridad	Realidad Técnica en una Brecha de Producción
Cifrado de datos en reposo (TDE)	Inútil contra la mayoría de las brechas de seguridad. El motor de la base de datos descifra automáticamente los datos de cualquier sesión validada. La mayoría de los ataques utilizan sesiones validadas, empleando, por ejemplo, credenciales robadas o el secuestro de la cuenta de la aplicación.
Cifrado de datos en tránsito (red)	Incapaces de detener la mayoría de las brechas de seguridad. Dado que los atacantes no analizan los paquetes en busca de fragmentos de datos, cifrarlos no sirve de nada. Eluden el cifrado utilizando conexiones existentes (por ejemplo, la aplicación) o creando nuevas conexiones validadas (por ejemplo, con credenciales robadas).
Conexiones de aplicaciones TLS/SSL	Ineficaz contra la mayoría de los ataques. Nadie puede vulnerar HTTPS, pero las brechas de seguridad ocurren a diario. La mayoría de los vectores de ataque a las aplicaciones crean una nueva conexión.

Para proteger los datos de producción, es necesario aceptar una verdad fundamental: los datos siempre estarán descifrados y accesibles a través de rutas de acceso «legítimas». Si la ruta de acceso se ve comprometida, el cifrado se elude por completo.

La Desilusión de la Seguridad de las Apps

La arquitectura moderna de tres capas trasladó la seguridad de la base de datos a la capa de aplicación. La base de datos se trata como un simple sistema de almacenamiento, y la autenticación y autorización del usuario final se gestionan completamente mediante el código de la aplicación.

Esta promesa de seguridad de las aplicaciones fracasó. Las aplicaciones están plagadas de errores y vulnerabilidades que los hackers explotan a diario. Muchas de estas deficiencias corresponden a fallos sistémicos comunes con nombres llamativos como inyección SQL, BOLA, XSS, entre otros. Pero la premisa subyacente de «dejar que la aplicación gestione la seguridad» se topó con un muro, ya que todas las aplicaciones tienen vulnerabilidades. Esto obliga a los equipos de seguridad y desarrollo a una carrera constante para detectarlas y corregirlas.

Todos los intentos de añadir componentes de seguridad sólidos, como Spring Security dentro de la aplicación y un WAF externo, no lograron proporcionar la protección necesaria. Las brechas de seguridad siguen ocurriendo a un ritmo alarmante.

No es que no se necesiten medidas de seguridad y prevención para las aplicaciones; simplemente no son suficientes. Nos hemos metido en este aprieto al confiar en la seguridad de las aplicaciones, y cuando eso falla, todo falla.

La Ilusión del Mínimo Privilegio en las BBDD

El enfoque estándar para el cumplimiento normativo consiste en aplicar controles de acceso de «mínimo privilegio» dentro de la base de datos. En entornos modernos, esta estrategia resulta ineficaz frente a ataques reales. Las arquitecturas de bases de datos concentran inherentemente privilegios masivos en un número reducido de cuentas. Francamente, las cuentas que no requieren acceso a los datos ni siquiera deberían existir en un entorno de producción.

• Cuenta de aplicación: Las aplicaciones requieren permisos generales de SELECCIONAR, INSERTAR, ACTUALIZAR y ELIMINAR sobre todos los datos para funcionar. Para la aplicación, la base de datos es simplemente un contenedor de almacenamiento, y la seguridad se implementa dentro de la aplicación, no en la base de datos.
• Cuentas de administrador con privilegios: Los administradores de bases de datos y las cuentas con privilegios tienen acceso ilimitado a los datos. Así funcionan los privilegios de la base de datos, y no se puede restringir el acceso de los administradores. Hay una buena razón para ello, y los intentos de limitar el acceso de los administradores suelen crear mecanismos demasiado complejos que, en última instancia, no logran su objetivo.

Los atacantes no inventan nuevas formas de acceder a la base de datos; secuestran las cuentas existentes. Dado que estas cuentas ya poseen acceso legítimo y autorizado a todos los datos, los controles de acceso estándar a la base de datos resultan ineficaces. La base de datos no puede distinguir entre un administrador de bases de datos real y uno falso, ni entre una instrucción SQL legítima de una aplicación y un hacker que extrae todos los datos.

Por lo tanto, no se pueden proteger los datos de producción gestionando permisos demasiado amplios. Es necesario cambiar por completo la arquitectura hacia el control de actividad: analizar cada conexión y cada instrucción para determinar qué es correcto y qué no.

Puede parecer desalentador o imposible, pero es la realidad de cómo debemos proteger nuestros datos. Con las tecnologías y los enfoques adecuados, es muy factible, y eso es lo que explicaremos en esta serie.

En caso de una brecha de seguridad, los atacantes inevitablemente aprovecharán las cuentas legítimas de la base de datos que pueden acceder a los datos. Si aceptamos esto, nuestra seguridad debe distinguir de alguna manera entre el comportamiento legítimo y el malicioso. Una conexión a la base de datos podría usarse con un propósito válido, ser utilizada indebidamente por un usuario interno malintencionado o ser explotada por un agente externo.

Para comprender cómo podemos distinguir entre lo bueno y lo malo, primero debemos profundizar en el delicado equilibrio entre los falsos positivos y los falsos negativos.

El Punto Ciego Arraigado

Cualquier control de seguridad opera en un espectro inevitable que equilibra dos métricas críticas: falsos positivos y falsos negativos. Gestionar este espectro determina el éxito o el fracaso de las operaciones de seguridad.

• Falsos positivos: El control de seguridad detecta o bloquea una actividad comercial legítima.
• Falsos negativos: El control de seguridad no detecta ni bloquea un ataque malicioso.

El secreto a voces de la seguridad empresarial es que siempre conocemos nuestros falsos positivos porque la empresa se alarma cuando se interrumpe la producción. Rara vez conocemos nuestros falsos negativos hasta que un tercero o una notificación de ransomware nos informa de una brecha de seguridad.

Reducir los falsos positivos inevitablemente aumenta los falsos negativos, y viceversa. Siempre pensamos en minimizar los falsos positivos, pero lo que realmente debería preocuparnos es minimizar los falsos negativos que desconocemos.

Las restricciones de la prevención

Al configurar los controles preventivos (bloqueo de tráfico), surge un dilema de ingeniería.

Para prevenir un ataque, el sistema debe tomar una decisión en tiempo real para cerrar una conexión o finalizar una consulta. Si la decisión es errónea, una transacción legítima de un cliente falla, una API deja de funcionar o un proceso de negocio crítico se detiene.

Dado que la continuidad del negocio siempre prevalece sobre las políticas de seguridad, la respuesta ante un falso positivo que interrumpe la actividad empresarial es siempre la misma: los equipos de ingeniería obligan a seguridad a reducir la sensibilidad.

Al configurar la herramienta de prevención para que nunca interrumpa las operaciones legítimas, se garantiza un aumento masivo de falsos negativos. Se crea un sistema configurado para ignorar la información y así evitar problemas.

En realidad, la mayoría de los sistemas preventivos vienen preconfigurados para ser menos sensibles, de ahí su menor eficacia.

Cabe aclarar que esto no significa que la prevención sea inútil o que no tenga cabida en la estrategia de seguridad. En el perímetro, por ejemplo, la prevención bloquea el 95 % de la actividad maliciosa y es esencial. Sin embargo, cuanto más profundo sea el perímetro, menos eficaz se vuelve. Y lo que es más importante, incluso si se alcanza una eficacia del 95 %, el 5 % restante de los ataques se convertirá en una filtración de datos.

El poder de la detección

Para lograr una seguridad sólida, el principio arquitectónico fundamental debe ser: prevenir lo que se pueda, detectar el resto.

Centrarse en los controles de detección elimina las limitaciones de la prevención. Dado que un control de detección alerta en lugar de bloquear, un falso positivo no interrumpe el negocio. Simplemente da lugar a una investigación interna que valida la sensibilidad del sistema de monitoreo.

Métrica de Postura	Postura de Prevención	Detección de la Postura
Riesgo operacional	Alto. Puede confundir una actividad legítima con un ataque y bloquearla.	Cero. Inspecciona la actividad sin interferir con las operaciones.
Ajuste de sensibilidad	Bajo. Debe estar suelto para evitar bloquear el tráfico de producción.	Potencialmente alto. Puede calibrarse con precisión para detectar comportamientos anómalos.
Puntos ciegos (falsos negativos)	Alto. Los ataques pueden pasar sin ser inspeccionados.	Potencialmente mínimo. Al aprovechar los enfoques que analizaremos en esta serie.

We should avoid alert fatigue from too many false positives, but a reasonable volume of False Positives is healthy, not a failure. It proves your security monitoring is calibrated to be sensitive enough to catch potentially malicious behavior within your «legitimate» access paths.

De la Teoría a la Práctica

Implementar una estrategia de detección centrada en datos en un entorno empresarial supone un gran desafío de ingeniería. Si es necesario inspeccionar cada conexión, cada sentencia SQL y cada actividad de la aplicación para descubrir intenciones maliciosas disfrazadas de tráfico legítimo, se trata de capturar y procesar miles de millones de actividades.

Históricamente, aquí es donde la teoría se topa con un obstáculo. Activar la auditoría nativa de la base de datos genera una sobrecarga de rendimiento catastrófica que puede superar el 40 % de los recursos del servidor de base de datos. En un sistema de producción de alto rendimiento, esta sobrecarga es insostenible. Los administradores de bases de datos deshabilitarán inmediatamente las herramientas para mantener el sistema en funcionamiento, dejando al equipo de seguridad completamente a ciegas.

Para superar este obstáculo, una arquitectura de detección centrada en datos debe cumplir tres criterios innegociables: debe capturar el 100 % de la actividad, procesar miles de millones de actividades para ofrecer un valor de seguridad real y hacerlo con un consumo operativo inferior al 5 % de la CPU.

Para demostrar que esto no es solo teoría académica, esta serie se basará en aplicaciones prácticas, utilizando arquitectura y pruebas de rendimiento modeladas a partir de nuestra propia plataforma, Core Audit, demostrando que se puede lograr una visibilidad del 100 % sin interrumpir la producción.

La arquitectura de Core Audit cumple con estos tres requisitos fundamentales al capturar la actividad en la base de datos y los motores de la aplicación, y realizar casi todo el procesamiento fuera de banda. La captura de la actividad en los motores garantiza una visibilidad total y mantiene la sobrecarga de la CPU por debajo del 3 %. El procesamiento fuera de banda libera la capacidad de cómputo para descargar los recursos de la CPU del servidor. También permite ejecutar algoritmos complejos y referencias históricas que brindan las capacidades requeridas por los enfoques de esta serie.

Superar la barrera del rendimiento elimina la excusa para la falta de visibilidad operativa, proporcionando a los equipos de seguridad las herramientas que necesitan para construir una arquitectura de detección sólida y sensible sin poner en riesgo la continuidad del negocio.

¿Qué Sigue?

Aceptar que el perímetro se ha vulnerado, comprometerse a proteger los datos mediante el control de la actividad y decidir detectar los ataques, no solo prevenirlos, es solo la filosofía básica. Para asegurar la empresa, ahora debe implementar esta estrategia. Comenzaremos a construir defensas desde adentro hacia afuera, empezando por la capa más profunda que rodea sus datos: la base de datos.

En los siguientes artículos, iremos más allá de la teoría y profundizaremos en la mecánica práctica de la protección de la base de datos y la aplicación. En la Parte 2, abordaremos los controles de sesión de la base de datos. Partiendo de estos controles sencillos, exploraremos la multitud de enfoques a nuestra disposición, incluyendo informes, alertas, anomalías y análisis forense proactivo.