En las tres primeras partes de esta serie, establecimos una metodología rigurosa centrada en los datos que construye la seguridad desde adentro hacia afuera. Comenzamos por la base de datos donde residen los datos y, dentro de ella, nos centramos en los activos de datos críticos y sensibles.

Sin embargo, una vez que un atacante ya está accediendo a sus datos confidenciales, ya no dispone de margen de maniobra. Debe detectar, evaluar y detener la exfiltración con rapidez. Es difícil determinar cuánto tiempo queda antes de que el atacante dé con la consulta SQL adecuada y ajuste sus herramientas, pero debe asumir que dispone de muy poco tiempo.

Al seguir este enfoque centrado en los datos, el siguiente paso lógico consiste en levantar otra barrera un poco más hacia el exterior. Confiar exclusivamente en una única barrera al borde del precipicio es una estrategia peligrosa.

Esto nos lleva al siguiente paso de la defensa desde adentro hacia fuera: la protección de los perfiles de actividad.

Esta defensa no sustituye a la barrera interna que rodea los datos sensibles. Aunque pretende ser rigurosa y exhaustiva, también actúa como un sistema de alerta temprana. Antes de que un adversario acceda a un activo sensible, casi siempre muestra un comportamiento anómalo.

Podemos crear un anillo defensivo adicional dentro de la base de datos clasificando distintos perfiles de usuario e identificando comportamientos inusuales que un atacante no puede evitar.

Perfiles de Actividad

La actividad de una base de datos no consiste en un conjunto aleatorio de consultas. Tiene objetivos y sigue ciertas reglas predecibles. El ecosistema cuenta con tipos de actores fundamentalmente diferentes que utilizan herramientas distintas para alcanzar objetivos totalmente distintos.

Si intentas aplicar una única política a toda tu base de datos, fracasarás. Lo que es un comportamiento anómalo para un actor es normal para otro. Detectar acciones que nadie debería realizar es casi imposible y no ofrece una defensa significativa.

Para crear una seguridad eficaz, debes dividir y conquistar. Debes clasificar las fuentes de actividad en perfiles de actividad distintos en función de su realidad operativa.

Tres pilares definen un perfil de actividad:

• Quién se conecta (el usuario de la base de datos).
• Cómo se conecta (por ejemplo, la aplicación cliente).
• Qué tipo de actividad lleva a cabo, centrándose en los comportamientos básicos de los que debe desviarse un ataque (por ejemplo, administración, consultas SQL repetitivas, recuentos bajos de filas u objetos objetivo).

Al establecer estos perfiles, se deja de tratar cada conexión a la base de datos como una fuente de actividad genérica. En su lugar, se crean conjuntos de reglas distintos y altamente personalizados para cada clase de usuario. Un actor malintencionado, ya sea interno o externo, debe desviarse del perfil de la cuenta para llevar a cabo un ataque. Cuando lo hace, se le detecta en la fase de aproximación, antes de que intente extraer datos y traspasar la barrera de protección interna de los datos.

¿Quién es la Amenaza?

Antes de analizar los perfiles individuales, debemos tener en cuenta contra quién nos defendemos. A nivel de la base de datos, diferentes amenazas y vectores de ataque pueden parecer iguales. Enumerar las amenazas ayuda a garantizar que las abordemos todas.

Cuando llega una conexión al listener de la base de datos, el motor solo sabe lo que le indica la cadena de conexión. No puede distinguir si la persona que está detrás del teclado es el titular autorizado de la cuenta o un adversario que se hace pasar por él. No puede conocer sus intenciones ni siquiera saber si se trata de una persona real.

En la práctica, todas las cuentas de bases de datos se enfrentan a tres vectores de amenaza básicos:

Amenaza	Fuente	Quién
Robo de Credenciales	Externa	Un atacante que utilice un nombre de usuario y una contraseña válidos
Suplantación de Identidad	Externa	Un atacante se hace con el control del ordenador de un empleado, de un servidor de aplicaciones o de una sesión de base de datos.
Abuso de Privilegios	Interna	El usuario autorizado legítimo con intenciones maliciosas

1. Robo de credenciales: un atacante obtiene un nombre de usuario y una contraseña válidos (de un archivo en el que estaban guardados, a través de un keylogger, etc.) y establece una conexión directa y no autorizada con la base de datos. Los ataques de robo de credenciales suelen proceder de una dirección IP diferente y también pueden utilizar un programa cliente distinto al del usuario real.
2. Suplantación de identidad cercana: un atacante compromete la estación de trabajo de un usuario autorizado, un servidor de aplicaciones o se hace con el control de una sesión de usuario activa. Estas conexiones son indistinguibles de las del usuario original y pueden haber sido iniciadas por el propio usuario.
3. Abuso de privilegios: un usuario legítimo y de confianza (un administrador de bases de datos descontento, un desarrollador deshonesto o un administrador de aplicaciones desesperado) utiliza intencionadamente su acceso autorizado para cometer actos maliciosos. Se trata de usuarios autorizados que saben cómo conectarse correctamente a la base de datos, tienen permiso para hacerlo y lo hacen con regularidad.

La conclusión es que las conexiones que parecen perfectamente válidas pueden utilizarse igualmente para actividades maliciosas. Aunque confiemos implícitamente en los usuarios legítimos, esas conexiones de apariencia legítima podrían corresponder a un atacante que los imita a la perfección.

En otras palabras, no importa si una conexión parece válida. Lo que importa es la actividad. La intención maliciosa, independientemente de quién la lleve a cabo, da lugar a acciones maliciosas. Estas acciones son las pistas que debemos identificar.

La pregunta «¿Cómo verificamos si se trata realmente de Bob o de un atacante que utiliza la contraseña de Bob?» es irrelevante. La respuesta es sencilla: no te importa. No necesitas resolver el problema de la atribución de identidad para detener un ataque. Simplemente tienes que detectar la desviación en la ejecución.

Da igual si confías en tus administradores de bases de datos o en tus desarrolladores de aplicaciones. Debes supervisarlo todo a ciegas, porque nunca puedes garantizar quién está al otro lado de la línea.

Desglose de Perfiles

Para crear perfiles de actividad eficaces, debes identificar la «debilidad» operativa fundamental de cada clase de usuario. Cada perfil tiene algo inherente que lo descarta como posible atacante. Algo esencial para un ataque y que debe vulnerarse para llevar a cabo una intención maliciosa.

Perfil	Perfil de Actividad	«Punto Débil» Clave
DBAs y cuentas con privilegios	Numerosos DDL, código SQL creado manualmente, scripts y herramientas especializadas.	No existe ninguna justificación comercial legítima para acceder a los datos.
Aplicaciones	Miles de millones de consultas SQL que acceden a cada dato. Consultas y modificaciones de datos confidenciales.	Patrones SQL muy recurrentes a la hora de eliminar literales.
Analistas y otros	Código SQL creado manualmente, scripts y herramientas especializadas.	Requieren acceso al esquema. Por lo general, no necesitan modificar datos, acceder a información de carácter personal ni extraer un gran volumen de filas.

Perfiles de DBAs y Operaciones

A primera vista, las cuentas de los DBA parecen una pesadilla en materia de seguridad. Tienen acceso ilimitado, a menudo con acceso directo al servidor. Son expertos en bases de datos con un profundo conocimiento de la configuración y la realidad operativa. Utilizan herramientas especializadas, ejecutan una mezcla caótica de código SQL escrito a mano, crean scripts personalizados y automatizan los procedimientos de mantenimiento. Entre sus tareas habituales se incluyen la revisión de las métricas internas de la base de datos, la realización de cambios en la configuración, la modificación de objetos en el esquema de datos, la modificación de usuarios y la concesión de permisos.

El punto débil: aunque los administradores de bases de datos mantienen la infraestructura, rara vez necesitan leer o escribir datos del esquema confidencial.

Un administrador de bases de datos puede necesitar modificar la tabla de tarjetas de crédito añadiendo columnas o índices, pero no necesita consultar los números de tarjeta de crédito que contiene.

La estrategia:

• Data Fence (Protección de datos): Permite generar alertas o bloquear cualquier consulta o sentencia DML dirigida al esquema de datos o a tablas sensibles. Los administradores de bases de datos (DBA) no necesitan acceder a los datos, pero los controles nativos de la base de datos no pueden garantizar esta restricción. Aislar a los DBA de los datos elimina la gran mayoría de los casos de explotación de sus cuentas, ya sea por amenazas internas o externas.
• Session Traps (Trampas de sesión): Permiten monitorear aplicaciones y direcciones IP de origen. Aunque los DBA utilizan diversas herramientas, por lo general se conectan desde equipos y redes administrativas designados. Es posible detectar fácilmente una anomalía cuando cambia el origen de la actividad. Este control es valioso contra el robo de credenciales de administrador, ya que actúa como una señal de alerta temprana.
• Monitoreo de DDL: Las sentencias DDL son comandos administrativos de la base de datos que se utilizan para gestionar la configuración, los usuarios, los permisos, los objetos, entre otros elementos. Las mejores prácticas dictan que deben utilizarse estrictamente bajo procedimientos de control de cambios. Monitorear la ejecución de DDL es una buena práctica que ayuda a garantizar que todas las operaciones estén vinculadas a tickets aprobados.
• Actividad local: Los DBA suelen utilizar conexiones locales dentro del servidor de la base de datos (por ejemplo, para iniciar o detener la base de datos). Si bien estas conexiones son necesarias para tareas administrativas, se emplean únicamente para actividades limitadas y muy específicas. Es fundamental generar alertas ante cualquier uso distinto a lo habitual, ya que el compromiso a nivel local constituye un vector de ataque significativo, explotado en todos los ataques de ransomware de doble extorsión.

Restringir o controlar las cuentas de los administradores de bases de datos (DBA) no es tan difícil como se suele pensar. Sin embargo, las bases de datos no cuentan con mecanismos integrados para limitar a los DBA, y lograr este control requiere soluciones de control de la actividad de las bases de datos.

Perfiles de Aplicaciones

Las aplicaciones representan más del 95 % de la actividad total de las bases de datos. Inundan el motor con miles de millones de ejecuciones SQL generadas automáticamente por el código de las aplicaciones para satisfacer las solicitudes de los usuarios finales. La revisión humana a esta escala es imposible.

El punto débil: las aplicaciones son intrínsecamente deterministas. Los usuarios hacen clic en botones y las rutas de código ejecutan plantillas SQL predefinidas. Incluso las aplicaciones altamente dinámicas que generan construcciones SQL basadas en la entrada del usuario acaban agotando sus formas de consulta únicas.

Aunque los literales cambian constantemente (por ejemplo, WHERE id = 623 frente a WHERE id = 9981), la construcción SQL subyacente permanece fija. Por lo general, en un periodo de referencia de 90 días, casi el 100 % de los patrones de consulta de las aplicaciones se repiten.

La estrategia:

• Anomalías en las construcciones SQL: Dado que las construcciones SQL se repiten inevitablemente, alertar ante una desviación pone de manifiesto un comportamiento anómalo de la aplicación. Por ejemplo, cualquier ataque de inyección SQL creará una construcción SQL que la aplicación no genera de forma nativa. Se trata de una señal de alerta temprana, ya que es poco probable que el primer código SQL inyectado sea el que provoque la filtración de datos.
• Errores: Cuando los atacantes intentan provocar un comportamiento anómalo en la aplicación (por ejemplo, causar una inyección SQL), realizan numerosos intentos fallidos que desencadenan errores. La supervisión de los errores proporciona una señal de alerta aún más temprana de una vulnerabilidad en la aplicación.
• Anomalías de volumen: Algunos vectores de ataque tienen como objetivo explotar las consultas SQL que la aplicación emite normalmente, pero a un volumen mucho mayor. Por ejemplo, un ataque BOLA escanea todos los identificadores posibles y extrae información de cada uno de ellos. La supervisión del volumen de consultas es un buen indicador de este tipo de comportamiento anómalo de la aplicación.
• Control de sesiones: Las cuentas de servicio de las aplicaciones solo se conectan desde programas conocidos en servidores de aplicaciones conocidos. Emitir una alerta o bloquear una cuenta de aplicación que se conecte desde una fuente de actividad diferente es una medida sencilla para prevenir el robo y el uso indebido de credenciales.

Es totalmente posible controlar la actividad de las aplicaciones. Contrariamente a lo que se suele creer, las soluciones de control de la actividad de las bases de datos ofrecen controles muy eficaces que detectan la mayoría, si no todas, las infracciones.

Perfiles de Analistas y de Consultas Ad-Hoc

Los analistas, las herramientas de BI y los usuarios que generan informes suponen el mayor desafío. Acceden a tablas de datos confidenciales, escriben consultas SQL ad hoc a mano y ejecutan uniones impredecibles.

El punto débil: los analistas necesitan visibilidad del esquema para llevar a cabo tareas de inteligencia empresarial, pero rara vez necesitan acceso directo a la información de identificación personal (PII) propiamente dicha. Por ejemplo, no necesitan ver números de la Seguridad Social ni datos de tarjetas de crédito. Cuando necesitan acceder a la PII, nunca se trata de grandes volúmenes (por ejemplo, para extraer miles de identidades). A menudo realizan el análisis dentro de la base de datos y no extraen muchos datos. Por último, no necesitan acceso administrativo ni de escritura a la base de datos, y esto se puede restringir mediante los controles integrados de la base de datos.

La estrategia:

• Mínimo privilegio: Elimina todos los privilegios administrativos y de acceso de escritura. Además, utiliza los permisos de la base de datos para revocar el acceso a tablas y columnas sensibles que no sean necesarias.
• Enmascaramiento: Si se requiere acceso parcial a la información de identificación personal (PII), puedes utilizar el enmascaramiento estático de datos para crear una tabla desensibilizada, el enmascaramiento dinámico para modificar los datos sobre la marcha, o una vista de la base de datos para aplicar funciones sencillas que restrinjan la visibilidad.
• Volumen de datos: Cuando los analistas realicen análisis dentro de la base de datos, establece alertas de umbral bajo o límites de bloqueo en el recuento de filas y el volumen de extracción de datos. Si extraen datos, asegúrate de que dichos límites impidan la extracción de datos de carácter personal.
• Desacoplamiento de identificadores y datos: Utilice los métodos anteriores descritos en «Enmascaramiento» para desacoplar los identificadores de los datos. Por ejemplo, puede permitir que vean los salarios y los nombres, pero no el nombre que corresponde a cada salario. Como alternativa, impida las uniones entre los datos y la información de identificación personal, obligando a que el acceso a dicha información sea independiente y de volumen limitado.

En la mayoría de los casos, estas restricciones se pueden aplicar mediante mecanismos integrados en la base de datos. Sin embargo, algunos mecanismos, como el control de volumen y la prevención de uniones, requieren soluciones más avanzadas de control de la actividad de la base de datos.

Análisis Forense Proactivo

No se pueden crear perfiles de actividad precisos basándose en suposiciones. Lo hemos intentado muchas veces y nunca funciona.

Cuando se enfrentan a la lista de programas que se conectan a la base de datos y a la lista de direcciones IP, los administradores de bases de datos (DBA) suelen pasar por alto algunos programas o quién utiliza esas direcciones IP. No es raro realizar investigaciones forenses para explicar cómo se produjeron determinadas actividades.

Adivinar el comportamiento de los usuarios garantiza dos resultados: enormes puntos ciegos de seguridad en los que no se ha logrado predecir la realidad, o una avalancha de alertas de falsos positivos que obliga a los equipos a desactivar ciertos controles. Lamentablemente, suele darse una combinación de ambos.

Una seguridad adecuada comienza con el análisis forense proactivo. Se trata de la capacidad de inspeccionar, consultar y analizar de forma retroactiva el 100 % de la actividad que tiene lugar en su base de datos a lo largo de periodos de tiempo prolongados. De este modo, la seguridad pasa de ser un ejercicio de conjeturas a convertirse en una ciencia empírica.

Antes de escribir una sola regla o activar una sola alerta, el análisis forense proactivo le permite contrastar sus hipótesis de seguridad con la realidad histórica:

• Hipótesis: «Nuestros administradores de bases de datos nunca realizan consultas SELECT en el esquema confidencial».
  Prueba: Analiza 90 días de actividad de los administradores de bases de datos, filtrando las sentencias DML y SELECT dirigidas a tablas confidenciales. Podrías descubrir, por ejemplo, que los administradores de bases de datos ocasionalmente descargan tablas de datos para determinados usuarios o corrigen valores de datos dañados.
• Hipótesis: «La cuenta principal de la aplicación solo utiliza dos programas y siempre se conecta desde el grupo de servidores de aplicaciones principal»
  Prueba: Analiza el origen de la actividad de la cuenta durante el último trimestre. Es posible que descubras, por ejemplo, que los desarrolladores utilizan esta cuenta con regularidad.
• Hipótesis: «Solo los scripts de mantenimiento autorizados ejecutan sentencias DDL».
  Prueba: Realiza una búsqueda forense de todas las ejecuciones de DDL y revisa la lista de usuarios y programas que las han ejecutado. Es posible que descubras, por ejemplo, que la propia aplicación también ejecuta ciertas sentencias DDL.

La comprobación de estas hipótesis pone de manifiesto, sin excepción, desviaciones operativas, tareas heredadas olvidadas, procesos paralelos no autorizados y prácticas de seguridad deficientes. Ajustar los controles a la realidad antes de aplicar las políticas es lo que distingue a un programa de seguridad eficaz de uno ruidoso e inmanejable.

Los Pasos de Implementación

Al reunir todos los conceptos tratados hasta ahora, se obtiene una hoja de ruta de implementación estructurada. Aunque hay cierto componente de arte en ello, debes abordar el diseño y la ejecución de la seguridad basada en perfiles como un proceso de ingeniería organizado.

1. Elaboración de perfiles mediante análisis forense proactivo

Utiliza datos forenses para identificar todas las cuentas activas:

• Fuente de la actividad: Conexión entre aplicaciones y direcciones IP o subredes de origen.
• Tipos de actividad: Por ejemplo, DDL, DML o consultas.
• Tiempo y volumen: Tiempo de actividad, volumen de ejecución de SQL y número de filas.
• Objetos: Tablas, vistas y procedimientos confidenciales, junto con el recuento de filas.
• Externa frente a interna: Actividad transmitida por la red frente a actividad interna procedente de procedimientos.

A veces, es necesario desglosar los perfiles de actividad por usuario y programa, en lugar de solo por nombre de usuario. Por ejemplo, cuando tanto los administradores de bases de datos como los scripts automatizados utilizan cuentas con privilegios.

En algunos casos, es mejor ir hacia atrás e identificar las cuentas que realizan la actividad. Por ejemplo, qué cuentas, programas y direcciones IP ejecutan sentencias DDL y cuáles acceden a datos confidenciales.

2. Establecer hipótesis iniciales sobre los perfiles

Agrupa tu inventario en perfiles de actividades principales, como administradores de bases de datos, aplicaciones y analistas. Para cada perfil, define los límites operativos fundamentales y las «debilidades» que pretendes controlar:

• Administradores de bases de datos (DBA): Limitar las acciones a las tareas administrativas e impedir el acceso a los esquemas de datos confidenciales.
• Aplicaciones: Vincularlas a programas y servidores fijos, y detectar desviaciones respecto a los patrones de construcción de SQL.
• Analistas: Revocar los privilegios de administración y escritura, restringir el acceso a tablas y columnas confidenciales, controlar los límites de extracción y enmascarar o desacoplar los datos de los identificadores.

3. Validación con respecto a una referencia histórica

Comprueba tus reglas propuestas con respecto a entre 30 y 90 días de actividad reciente. Identifica los casos en los que una regla se habría activado y determina:

• Verdaderos positivos: ¿Cuántas alertas indican una amenaza real, requieren una solución operativa o, de algún modo, se benefician de la atención del personal de seguridad?
• Falsos positivos: ¿Cuántas son falsos positivos?
• Carga de revisión: ¿El volumen de alertas es excesivo o aceptable? Un número razonable de alertas es saludable. Es el sello distintivo de una seguridad sensible y rigurosa.
• Ajuste necesario: ¿Deberías ajustar las alertas, por ejemplo, filtrando determinadas actividades?
• Perfiles coherentes: ¿Deberías ajustar los límites de los perfiles? Puede ser necesario si la combinación de diferentes perfiles provoca demasiadas alertas.
• Valor: ¿Se trata de una alerta valiosa y eficaz que pondrá de relieve un posible incidente de seguridad, o deberías reevaluar el perfil de vulnerabilidades?

4. Aplicación y alertas

Convierte tus políticas en medidas activas de detección o prevención. Dado que has validado previamente tus hipótesis, el volumen de alertas debería ser predecible y ajustarse a tus expectativas.

Recuerda que el objetivo no es alcanzar cero falsos positivos. La ausencia total de falsos positivos implica, inevitablemente, que hay muchos falsos negativos y que tu seguridad es ineficaz. El objetivo es alcanzar un nivel de alertas adecuado y manejable. Lo suficiente para garantizar que el personal de seguridad sea consciente de la realidad operativa y la supervise de cerca.

5. Auditoría periódica y escalado de madurez

Los perfiles de actividad de las bases de datos no son estáticos. Las aplicaciones cambian, se incorporan nuevos usuarios y otros dejan de utilizar el sistema, los administradores de bases de datos (DBA) actualizan sus herramientas y scripts, y las unidades de negocio adoptan nuevas plataformas de BI. Todo cambia, y su seguridad también debe evolucionar.

Realiza una auditoría forense proactiva al menos una o dos veces al año. Utilícela para revalidar sus perfiles y el enfoque empleado para protegerlos. Considere lo siguiente:

• Actividad: Cuentas recién creadas, cambios en los grupos de direcciones IP o modificaciones en los patrones de SQL.
• Controles: Eficacia de las medidas existentes. ¿Es momento de eliminar algunas alertas o de implementar otras nuevas?
• Cobertura y brechas: ¿Cubren los controles actuales toda la actividad? ¿Son controles rigurosos o existen lagunas que podrían permitir una posible brecha de seguridad?
• Vectores de ataque: ¿Mitigan los controles los vectores de ataque que le preocupan y son capaces de mitigar los riesgos que ya ha identificado?
• Rendimiento histórico: ¿Cómo funcionaron los controles durante el periodo anterior? ¿Detectaron problemas de seguridad reales? ¿Tiene constancia de problemas no detectados? ¿Generan demasiadas alertas o consumen excesivo tiempo del personal?
• Madurez: A medida que mejore su visibilidad y adquiera experiencia con los controles, aproveche estas revisiones periódicas para optimizarlos aún más. Intente abordar perfiles o vectores que anteriormente consideraba demasiado complejos.

De la Teoría a la Práctica

La mayoría de los productos de seguridad de bases de datos se comercializan como un conjunto de funcionalidades: una caja de herramientas que los proveedores ponen en sus manos, esperando que usted las transforme en un programa de seguridad funcional. La responsabilidad de determinar cómo proteger sus datos recae, en última instancia, sobre usted.

Esta serie de artículos propone una metodología lógica y estructurada para convertir dicho conjunto de herramientas en una defensa sólida.

Con Core Audit, Blue Core Research no ofrece simplemente una colección de funciones, sino una manera de integrarlas en una implementación estratégica robusta. El perfilado de actividad que hemos descrito no es un mero ejercicio teórico; es la forma en que puede utilizar Core Audit para proteger sus datos.

No obstante, en lugar de pasar por alto aquellos aspectos de los requisitos de implementación que Core Audit gestiona de forma implícita, profundicemos un poco más en lo que implica llevar esta teoría a la práctica.

Control Ineludible

Uno de los pilares de esta guía es la protección de las cuentas de administrador de bases de datos (DBA). Al proteger cuentas con privilegios, usted se defiende frente a actores que conocen el motor de la base de datos mejor que nadie: ellos lo instalaron, lo configuraron y lo administran a diario. Intentar supervisar o restringir a un DBA mediante mecanismos de auditoría superficiales —fáciles de eludir— o proxies de red equivale a intentar detener una bala con una toalla de papel mojada.

Para controlar eficazmente a los DBA o a los atacantes que operan con privilegios administrativos, Core Audit impone una visibilidad y un control completos e ineludibles directamente en el núcleo del motor de la base de datos:

• Captura integral de la actividad en el origen: Captura el 100 % de la actividad, incluidas las conexiones locales dentro del servidor de bases de datos, el tráfico cifrado, el SQL dinámico y la actividad interna de la base de datos ejecutada mediante procedimientos almacenados y disparadores (triggers).
• Aplicación de políticas ineludible: Cuando una política establece que una cuenta de administrador de bases de datos (DBA) no puede ejecutar una instrucción SQL específica, Core Audit la bloquea a nivel del motor. No presenta puntos ciegos, soluciones alternativas, puertas traseras de conexión local ni vías de elusión mediante cifrado que un usuario interno o un atacante pudieran aprovechar.

El Repositorio de Seguridad

El motor que impulsa el análisis forense y de anomalías proactivo es el repositorio de seguridad patentado de Core Audit. Solo puedes investigar perfiles de actividad a lo largo de los meses cuando tengas los datos. Es trivial cuando tienes la herramienta adecuada e imposible sin ella.

Core Audit tiene dos repositorios, ambos hiperoptimizados. El repositorio de seguridad es responsable de la captura automática a largo plazo. Registra todo lo que sucedió en la base de datos independientemente de las políticas. Comprime toda la actividad de la base de datos a menos de 100 MB por mes por instancia. Aproximadamente un gigabyte de espacio en disco por año.

Una huella de esta magnitud cambia por completo las matemáticas sobre la seguridad de las bases de datos:

• Historial de consulta ilimitado: No está limitado a una ventana de retención de 30 o 90 días. Puede conservar años de historial forense completo en línea y disponible para búsquedas instantáneas, sin afectar los presupuestos de almacenamiento ni el rendimiento.
• Ventanas de referencia flexibles para anomalías: Si bien una ventana de referencia de 30 a 90 días suele bastar para eliminar falsos positivos en las estructuras SQL de las aplicaciones, usted tiene la libertad de ampliar el historial de referencia tanto como lo exija su realidad operativa. Asimismo, puede utilizar distintas ventanas de referencia para diferentes anomalías, según corresponda.

Uno de los «trucos» que emplea el Repositorio de Seguridad es la eliminación automática de literales. Este sistema contabiliza las ejecuciones de estructuras SQL únicas en lugar de tratarlas como sentencias SQL inconexas. Así es como logramos almacenar información forense sobre miles de millones de ejecuciones SQL ocupando muy poco espacio en disco.

La eliminación de literales también permite al motor de detección de anomalías realizar un seguimiento de dichas ejecuciones a lo largo del tiempo. Cuando una cuenta de aplicación ejecuta repentinamente una sentencia SQL que nunca antes había generado —como un fragmento de SQL inyectado—, el motor detecta la anomalía y le alerta sobre un ataque incipiente antes de que se produzca la exfiltración de datos.

Capacidades Adaptadas a tu Realidad Operativa

La seguridad no es una solución estandarizada de talla única. Las herramientas y los controles que implemente dependen totalmente de su equipo, su entorno y su realidad operativa:

• Reglas declarativas frente a detección de anomalías: Algunos entornos prosperan gracias a reglas explícitas y declarativas (por ejemplo, vincular cuentas de servicio a direcciones IP específicas). Otros dependen en gran medida de la detección automatizada de anomalías. Los programas de seguridad eficaces suelen emplear una combinación pragmática de ambos enfoques.
• Análisis forense como control fundamental: El análisis forense proactivo es un control de seguridad continuo, no solo una fase de configuración. Permite a los operadores humanos examinar el comportamiento operativo real, mientras que el análisis forense reactivo facilita investigaciones exhaustivas e inmediatas cuando se producen incidentes de seguridad.
• Progreso al propio ritmo: Dominar la seguridad de las bases de datos requiere tiempo, y cada organización sigue una trayectoria de madurez diferente. Core Audit ofrece una gama completa de capacidades desde el primer día, lo que le permite ganar confianza a su propio ritmo. Se comienza con la visibilidad, se añaden informes y alertas basados ​​en reglas declarativas y detección de anomalías, y se amplían gradualmente las políticas a medida que se adquiere control sobre el entorno. El bloqueo activo suele ser un componente que se incorpora en una etapa posterior de dicho proceso.

La cuestión es que, si bien no se utiliza todo desde el primer día, cada cliente emplea diferentes funcionalidades de distintas maneras y evoluciona siguiendo su propia trayectoria. Es como disponer de una paleta completa de colores para pintar un cuadro único; para tener éxito, es necesario tener acceso a todas esas capacidades.

Reflexión Final

Proteger las bases de datos no consiste en identificar las pocas conexiones que podrían provocar una brecha de seguridad, ni en confiar ciegamente en credenciales autenticadas. Se trata de clasificar la actividad de forma sistemática, reconociendo que cada actor opera dentro de una realidad operativa específica y exigiéndole que se ajuste a ella.

Al segmentar el tráfico de su base de datos en perfiles de actividad personalizados, deja de ir a remolque de las firmas genéricas. Obliga a los atacantes, a los usuarios internos malintencionados y a las credenciales comprometidas a revelarse durante la fase de aproximación, lo que proporciona a su equipo de seguridad el tiempo de reacción crítico necesario para actuar antes de que se vean comprometidos datos confidenciales.

Proteger las bases de datos no es imposible; ni siquiera es tan difícil. Solo requiere una metodología práctica y algo de esfuerzo. Empiece por la visibilidad, investigue cada perfil y ajuste las alertas. Así construirá un perímetro de detección resiliente en torno a su base de datos.

Pruebe Core Audit hoy mismo y acompáñenos en la siguiente entrega de esta serie, donde daremos el siguiente paso lógico en el proceso de madurez: el bloqueo activo. Analizaremos cómo pasar de la detección a la prevención, qué vías son más seguras y cómo reducir el riesgo para sus datos sin interrumpir la producción ni alterar la realidad operativa.