Invertimos millones en firewalls y EDR para proteger el perímetro y los endpoints. Pero el verdadero valor, sus datos, a menudo reside en una bóveda protegida por un candado de 25 años. Nuestra información es lo que buscan los atacantes, pero es lo que menos protegemos. En una casa hecha de puertas, nos obsesionamos con las puertas y descuidamos la bóveda. Precisamente lo que buscan los intrusos.

Si tiene mejor visibilidad de los correos electrónicos de phishing de los empleados que de los comandos SQL que atacan sus tablas más sensibles, debería considerar reajustar sus prioridades de seguridad. La atención que dedica a la protección del perímetro y los endpoints se invierte mejor en sus datos, alojados en bases de datos protegidas por soluciones obsoletas, parciales y demasiado caras.

¿Ha revisado recientemente la tecnología que utiliza para proteger sus bases de datos? Quizás esté mucho más al tanto de los antivirus más recientes que de los últimos avances en protección de bases de datos. Sin embargo, anticiparse a las amenazas significa no quedarse atrás en la curva tecnológica. Hagamos un repaso rápido. Puede comparar el estado de sus defensas con la tecnología de seguridad de base de datos actual.

No Puedes Proteger lo que no Puedes Ver

La visibilidad es la base de la seguridad. Muchos equipos construyen sus defensas basándose en la teoría, no en la realidad. Crean alertas para lo que imaginan que está sucediendo, sin ser conscientes de lo que realmente ocurre dentro de sus sistemas.

Pon a prueba tu postura: ¿Conoces a los usuarios y programas que se conectaron a tu base de datos la semana pasada? ¿Sabes qué hicieron? Si no lo sabes, ¿crees que es información crucial que deberías tener? Sin visibilidad, es probable que tengas actividad sin protección (puntos ciegos) y defensas contra actividad imaginaria inexistente. ¿Cómo calificarías la eficacia de tu seguridad entre un 10 y un castillo de naipes?

La Captura de Datos Impulsa Nuestras Defensas

Más allá de los requisitos de visibilidad, los datos son la base de una solución de seguridad. Generan informes, alertas, acciones de bloqueo y más. En una solución de control de actividad, todo se basa en conocer la actividad. No se puede alertar sobre actividades que no se han visto, ni bloquearlas.

Si bien proporcionar visibilidad histórica de todo lo ocurrido es tecnológicamente más complejo (véase más adelante), algunos de los requisitos tecnológicos fundamentales son los mismos.

Barreras Tecnológicas de Datos

Lograr una visibilidad del 100 % es un desafío técnico monumental que las soluciones más antiguas no logran ofrecer. La tecnología de captura es la base de la visibilidad y es la más costosa en las soluciones de control de actividad. Ahí es donde se nota la antigüedad del producto. Los proveedores tradicionales nunca reemplazan sus motores de captura principales; solo cambian la interfaz de usuario sobre sus bases de 25 años. Esas soluciones aún utilizan, hoy en día, tecnología de captura de hace un cuarto de siglo.

Actualmente, dividimos el control de actividad de bases de datos en tres generaciones:

• 1.ª generación: se basa en capacidades de auditoría de bases de datos integradas para los datos capturados.
• 2.ª generación: Captura de paquetes de comunicación. Desarrollado en respuesta a la sobrecarga de rendimiento.
• 3.ª generación: Captura de actividad desde el motor SQL. Desarrollado en respuesta a la falta de visibilidad y la seguridad ineficaz.

Todas estas generaciones tecnológicas deben superar tres obstáculos principales para ofrecer una seguridad eficaz. Comenzaremos con una tabla y explicaciones generales:

Característica	1era Generación Auditoría nativa	2nda Generación Captura de Paquetes	3ra Generación Captura de motor SQL
Gastos Generales de Rendimiento	Alta	Alta carga de red	Baja
Visibilidad	Extremadamente limitada (por rendimiento)	Limitado (por tecnología de captura)	Completa y hermética
Almacenamiento	Extremadamente limitado (por rendimiento)	Limitado y costoso (por la tecnología de almacenamiento)	Repositorio dual: primario eficiente + alternativo de 360°
Uso y Objetivo	Soluciones de gama baja. Superar auditorías básicas.	Cumplimiento en su mayoría. (Casilla de verificación de cumplimiento)	Cumplimiento + Detección y respuesta ante infracciones.

Algunos detalles más, pero el análisis técnico profundo se encuentra hacia el final del artículo:

1. Impacto en el rendimiento: Las bases de datos son máquinas altamente optimizadas, y capturar los miles de millones de SQL que ejecutan sin afectar su rendimiento es un desafío enorme.
   
   Las soluciones de auditoría tradicionales (1.ª generación) se basan en capacidades integradas de bases de datos, conocidas por su impacto devastador en el rendimiento. No podemos elegir entre «rápido» y «seguro»; debemos tener ambos. Por lo tanto, todas las generaciones futuras se ven impulsadas por la necesidad de capturar la actividad sin afectar el rendimiento. Tanto las tecnologías de 2.ª como de 3.ª generación pueden monitorizar a escala sin un impacto significativo, pero la 3.ª generación ofrece mejores resultados.
2. Puntos ciegos: Las bases de datos son máquinas complejas que ofrecen múltiples vías para conectar y ejecutar actividades. Dado que no podemos predecir la trayectoria de un ataque, debemos ver todo lo que sucede en todas partes. Esto se vuelve aún más vital, ya que los ataques inteligentes buscan deliberadamente la sombra.
   
   Los productos de primera generación podían, en teoría, verlo todo. Sin embargo, el impacto en el rendimiento significaba que verlo todo no era realista, y tuvimos que conformarnos con un subconjunto minúsculo de la actividad. Al pasar de la primera a la segunda generación, ganamos rendimiento, pero perdimos visibilidad. Las soluciones de segunda generación tienen limitaciones significativas con la actividad local (dentro de la caja), el tráfico cifrado y las SQL internas (como bloques anónimos, procedimientos almacenados y desencadenadores). Explicaremos los detalles más adelante, pero en el mundo de la ciberdelincuencia, un punto ciego es una invitación, y las soluciones de tercera generación siempre pueden verlo todo, cerrando esa puerta. Resolver el problema de visibilidad sin afectar el rendimiento permite a las soluciones de tercera generación ofrecer una captura completa y continua con un impacto insignificante en la base de datos. Esta es la razón principal de la evolución de esta tecnología.
3. Almacenamiento: Pasar de la captura a la visibilidad y el análisis avanzado requiere mantener un registro de todo lo capturado (todo lo ocurrido). Capturar la actividad sin registrarla no es tan útil.
   
   Las soluciones de 1.ª y 2.ª generación solo ofrecen una opción: registrar SQL individuales. Estos repositorios también requieren un espacio de disco considerable, lo que requiere reglas que permitan seleccionar qué registrar. Las soluciones de 3.ª generación incorporan una estrategia de repositorio dual: un repositorio principal que registra SQL individuales (pero de forma más eficiente) y un repositorio alternativo con datos agregados sobre toda la actividad. El repositorio principal es más eficiente porque elimina textos duplicados, alcanzando una densidad de capacidad de mil millones de SQL en 32 GB de espacio de disco. Sin embargo, el repositorio agregado alternativo es el gran diferenciador. Por unos pocos megabytes al día, este repositorio secundario garantiza que siempre se sepa qué ocurrió. Impulsa capacidades que ofrecen una visibilidad, un desglose y un análisis excepcionales. El repositorio dual no solo ahorra espacio de disco; transforma por completo la forma en que gestionamos la seguridad.
   
   Si ocurrió una filtración hace 6 meses, esta tecnología es tu única forma de «viajar en el tiempo» y saber qué hizo la aplicación un martes a las 2 a.m. Además, es la única tecnología que puede alertarte a tiempo para que no te enteres 6 meses después.

Las soluciones modernas y avanzadas de tercera generación son las únicas que satisfacen todos los requisitos y ofrecen defensas eficaces. Sin embargo, la mayoría de los productos están diseñados para cumplir con las normativas de seguridad parcial y débil.

La captura con SQL Engine de tercera generación ofrece lo mejor de ambos mundos sin sacrificar la calidad. Es la arquitectura que elegimos para desarrollar Core Audit, ya que creemos que es la única forma de satisfacer los requisitos de seguridad de las empresas modernas. Ofrece una visibilidad a la que la primera generación solo podía aspirar y un impacto mínimo en el rendimiento, inferior al de la segunda generación. Combinada con un potente motor de almacenamiento que nos permite aprovechar todos esos datos, la tercera generación es la mejor solución de su clase.

Confianza Cero, Verificar Siempre

Tener datos es solo la mitad del camino. Luego debemos usarlos para ganar seguridad. La primera pregunta es ¿qué tipo de seguridad esperamos lograr? ¿Queremos reducir los requisitos e ignorar gran parte de la actividad, o queremos asegurarlo todo?

Puede parecer una pregunta capciosa, pero expliquemos. Algunas personas creen que con miles de millones de SQL no pueden asegurarlo todo. Piensan que deben centrarse en unas pocas cosas, y que incluso esas serán demasiado para manejar. Esa es la perspectiva tradicional. Hoy en día, nuestro objetivo es asegurarlo todo. No dar por sentado que alguien o algo es seguro porque nadie lo es. Este cambio en los requisitos y expectativas fundamentales impulsa un enfoque muy diferente para el control de la actividad.

Esa es la cuestión de la Confianza Cero.

La perspectiva tradicional asume que ciertos usuarios autenticados son quienes dicen ser y que lo que hacen es seguro. Confían implícitamente tanto en la identidad (el nombre de usuario es la persona al otro lado de la conexión) como en su comportamiento (son «buenas personas»). La seguridad moderna asume lo contrario.

En una mentalidad de «no confiar en nada», no podemos confiar ni en la identidad ni en el comportamiento. No se trata solo de la amenaza interna, como sospechar de los administradores de bases de datos (DBA) y los administradores de aplicaciones. Se trata de la realidad de la autenticación: nunca podemos estar seguros de quién está al otro lado de la línea. Significa que monitoreamos la cuenta, no solo a la persona. Esa es la realidad del panorama de amenazas:

• Objetivos Principales: Las cuentas de DBA y de aplicaciones son los objetivos, y los atacantes buscan suplantarlas. Además, estas personas también representan el mayor riesgo de abuso de privilegios.
• Robo de Credenciales: El robo de credenciales no es una posibilidad, sino un vector de ataque principal. Por ejemplo: registradores de pulsaciones de teclas, acceso a archivos utilizados por administradores para almacenar contraseñas o la recuperación de la contraseña de la aplicación. Obtener credenciales válidas para conectarse a una base de datos no es trivial, pero tampoco imposible. Esto significa que no se puede asumir que el inicio de sesión de un administrador de bases de datos (DBA) coincida con su intención. Afortunadamente, el robo de credenciales suele sugerir que la conexión proviene de una fuente de actividad diferente (máquina o aplicación), y estas se pueden identificar mediante controles de sesión sencillos.
• Endpoints Comprometidos: El escritorio de un administrador de base de datos (DBA) de confianza podría estar bajo el control de un hacker remoto. Los atacantes pueden conectarse desde la misma máquina y aplicación que usa el DBA, lo que los hace indistinguibles de la persona real. Este vector de ataque solo puede identificarse inspeccionando las acciones realizadas dentro de la conexión (las SQL).

Incluso si confías en tus usuarios internos (cosa que no deberías), no puedes confiar en una conexión a la base de datos originada por esa persona. Un ataque malicioso eventualmente se manifestaría a través de una cuenta de base de datos válida. Por lo tanto, debemos controlar cada SQL en cada cuenta, ya que así es como nos atacan.

Asunto	Pregunta	Observando	Tipo de Control	Aprovechado Por
Identidad	¿Quién eres?	Nombre de usuario	Autenticación	Robo de credenciales
Contexto	¿De donde vienes?	Máquina y programa remotos	Control de sesión	Abuso o compromiso de endpoints
Comportamiento	¿Qué estás haciendo?	SQL	Reglas y anomalías	Ninguno

Proteger todo parece una tarea monumental, pero es la única manera de garantizar la seguridad hoy en día.

Pon a prueba tu postura: ¿Podrías detectar un ataque si un atacante usara un escritorio de administrador de base de datos comprometido para conectarse a la base de datos? ¿Sabrías si un administrador de base de datos decide robar datos? ¿Recibirás una alerta de exfiltración de datos desde el servidor de la base de datos por alguien que haya penetrado en la máquina? Estos no son vectores de ataque marginales menores. Son un componente central del panorama de amenazas. Si no puedes ver la actividad o no puedes analizarla bien, es poco probable que puedas detener estos ataques o incluso enterarte de que ocurrieron.

Confianza Cero y Captura

Además del reto de proteger miles de millones de SQL, la Confianza Cero plantea requisitos rigurosos para la captura de actividad:

• Independencia de Captura: si la captura depende de cualquier persona con acceso a la base de datos, implícitamente confiamos en esa persona. En concreto, confiar en los administradores de bases de datos (DBA) para gestionar la captura de la actividad de la base de datos requiere que confiemos en ellos. Este es un problema importante con la primera generación.
• Puntos Ciegos: un punto ciego en la captura es justo lo que buscan los atacantes. Es como un rincón oscuro que no está cubierto por una cámara de seguridad. Sobre todo cuando algunas de las personas en las que no deberíamos confiar son profesionales de bases de datos cualificados que conocen a fondo nuestras defensas. Evitar la tecnología de captura debería ser imposible, y ese es un problema importante con las soluciones de segunda generación.
• Flujo Constante: la captura debe enviar los datos fuera de la máquina lo más rápido posible. El servidor de auditoría debe recibir un flujo de toda la actividad de la base de datos casi en tiempo real. De lo contrario, se crea una vulnerabilidad que permite a los atacantes intervenir o manipular los datos. Este es uno de los problemas de las soluciones de primera generación.
• Bloqueo Hermético: al igual que con el problema del punto ciego, evitar el bloqueo también debería ser imposible. Si existe una política que impide que un administrador de bases de datos (DBA) toque una tabla sensible, no debería poder hacerlo. Punto. Esta es una preocupación importante tanto para las soluciones de primera como de segunda generación.

Puede parecer obvio, pero dadas las tecnologías dominantes en el mercado, es necesario enfatizar que una solución con puntos ciegos o debilidades obvias y bien conocidas no es una solución de seguridad eficaz. Si bien no son completamente inútiles, estas soluciones son algo que definitivamente debería intentar reemplazar.

La Brecha de la Aplicación

La aplicación es un vector de ataque común y, con frecuencia, resulta ser el eslabón más débil. La inyección SQL sigue siendo una amenaza importante, y las fallas de la aplicación son la principal puerta de entrada a la base de datos.

Asegurar el software de la aplicación es una tarea interminable. Las directrices de programación y las revisiones de código son esenciales, pero ofrecen beneficios limitados. Por lo tanto, debemos proteger la aplicación también a través de la base de datos. Ignorar el 99 % de la actividad de la base de datos porque es «demasiado difícil» o porque no sabemos cómo hacerlo es un punto ciego estratégico que no podemos permitirnos.

Sobre todo porque con la tecnología adecuada, no es nada difícil. El Análisis del Comportamiento de Aplicaciones puede comparar el comportamiento actual de la aplicación con el de los últimos meses y alertarnos de cualquier cambio. Este no es el único uso del análisis de anomalías, pero sí el más crítico.

Pon a prueba tu postura: ¿Percibirás un ataque de inyección SQL desde la aplicación? Esta es una de las debilidades más conocidas de las aplicaciones, pero no la única. Si no puedes detectar un vector de ataque principal como este, ¿se consideran tus defensas efectivas?

Pruebas de Postura de Seguridad

Hasta ahora, hemos presentado varias pruebas para evaluar tu nivel de seguridad actual. Un sistema de seguridad adecuado debería ser capaz de gestionarlas todas. Ni siquiera hemos analizado los ataques complejos. Estos son vectores de ataque principales que cualquier defensa de bases de datos debe abordar.

Debe poder afirmar con seguridad que sí, sabe lo que ocurre en su base de datos. Y sí, detectará un ataque desde un escritorio de administrador de base de datos comprometido. Y sí, detectará a administradores de base de datos que abusan de sus privilegios. Y sí, detectará un ataque de inyección SQL.

Afirmar esto es vital, ya que así es exactamente como los atacantes obtienen sus datos. No se trata de una teoría. Es precisamente la batalla a la que se enfrenta. También es la razón por la que la mayoría de las brechas de seguridad son detectadas por terceros: el personal de seguridad no puede detectar la mayoría de los ataques.

Si busca una solución que cumpla con estos estándares de tercera generación, en Blue Core Research nos centramos precisamente en esto. Proteja su base de datos adecuadamente para evitar ser una presa fácil, destinada a convertirse en una estadística más.

Barreras Tecnológicas Para Asegurar Todo

Pero apuntemos más alto. No nos limitemos a atacar ataques conocidos. No queremos hacer lo mínimo indispensable, sino lo máximo. Esto significa asegurarlo todo. Controlar cada SQL de la base de datos.

Como se imaginarán, configurar controles para asegurar cada SQL en cada conexión de base de datos no es tarea fácil. Requiere una combinación de metodologías y tecnologías de soporte. Pero con las herramientas adecuadas, podemos proteger cada uno de esos miles de millones de SQL.

El enfoque exacto debe adaptarse a cada base de datos, pero generalmente implica una combinación de estas metodologías:

1. Control de sesiones: Como práctica de seguridad recomendada, es recomendable controlar las cuentas, los programas y las IP que se conectan a la base de datos. Un comportamiento que se desvía de los patrones habituales es una señal de alerta que no debe ignorarse.
2. Cuentas que no requieren acceso a datos confidenciales: Algunas cuentas, como las de los administradores de bases de datos (DBA), no deberían acceder a datos confidenciales (ni siquiera al esquema de datos). Alertar o bloquear dicho acceso es un control simple que prácticamente elimina el riesgo en estas cuentas.
3. Acceso anómalo a datos sensibles: La mayoría de los accesos a datos sensibles se producen siguiendo patrones predecibles. Siempre se trata de las mismas SQL y, por lo general, provienen de la misma fuente. Identificar un cambio en el comportamiento de acceso a datos sensibles es un indicador esencial de un posible ataque.
4. Análisis del comportamiento de las aplicaciones: Las aplicaciones ejecutan miles de millones de SQL, pero estos se repiten. Al observar el comportamiento de las aplicaciones, las soluciones pueden detectar fácilmente cambios en los patrones de actividad. Cualquier ataque o intento de ataque a una aplicación activará inevitablemente esta alerta.
5. DDLs: La validación de los DDL que se obtienen mediante un proceso de control de cambios es fundamental para evitar cambios no autorizados en los metadatos. Si bien la mayoría de los DDL son legítimos, los no autorizados requieren investigación.
6. Recuento de filas y más: las soluciones ofrecen muchos más controles, como monitorear cuántos datos se extraen, quién lo hace, cuándo, cuántos SQL se utilizan y más.

En definitiva, no existe una fórmula mágica para proteger todos los SQL de la base de datos. Siempre se trata de dividir y vencer. Pero necesitamos tecnologías suficientes para gestionar cada subconjunto de esa división.

Análisis Profundo de la Tecnología

Ahora, abramos el capó y echemos un vistazo al interior. Comprendamos las barreras de estas tecnologías y por qué existen tantas.

Auditoría Nativa de 1ra Generación

La auditoría nativa es un término general que se refiere a la funcionalidad que viene integrada en la base de datos de forma gratuita. En pocas palabras, se le pide a la base de datos que registre lo que sucede dentro de ella. Por ejemplo, la auditoría nativa de Oracle o SQL Server. La auditoría nativa es conocida por tener un impacto devastador en el rendimiento, y este impacto se debe a tres obstáculos convergentes en la implementación:

• Datos adicionales necesarios: cuando las bases de datos registran actividad, necesitan registrar información adicional que normalmente no está disponible en la función que realiza el registro. Por ejemplo, registrar una línea de auditoría de una ejecución SQL requiere que la base de datos busque otra información relevante, como el nombre de usuario y el programa.
• E/S de disco: registrar la actividad implica escribir en el disco. Si los registros se escriben en una tabla de la base de datos, esto también implica pasar por los diversos mecanismos ACID que la base de datos utiliza para evitar la corrupción.
• Actividad en línea: las bases de datos realizan toda esta actividad de registro adicional como parte de la transacción. En otras palabras, la transacción de la base de datos debe esperar a que la base de datos recopile los datos necesarios y escriba todo en el disco. Cada transacción registrada sufre un retraso significativo y, en ocasiones, también hay transacciones que no se registran.

Además, las soluciones de primera generación dependen de un administrador de bases de datos (DBA) para configurar y mantener las funciones de auditoría pertinentes en la base de datos. Esto significa que la primera generación tiene un control extremadamente limitado de la actividad del DBA. Para auditar a los DBA, la captura debe ser independiente de ellos. No se pueden controlar eficazmente las cuentas utilizadas para controlar el mecanismo de captura.

En resumen: la tecnología de captura de primera generación solo se puede utilizar para una pequeña fracción de la actividad, e incluso así, con un impacto medible en el rendimiento y una eficacia limitada. Tampoco es ideal para controlar las cuentas del DBA. Sin embargo, la ventaja de la primera generación es que puede acceder a cualquier actividad de la base de datos, algo con lo que solo la tercera generación puede competir.

Captura de Paquetes de 2da Generación

La tecnología de captura de paquetes de bases de datos se desarrolló originalmente a finales de la década de 1990 para la monitorización del rendimiento de las bases de datos. A principios de la década de 2000, se adaptó al cumplimiento normativo de las bases de datos. Esta era la mejor tecnología de seguridad de bases de datos en aquel momento y aún se comercializa. Los principales proveedores actuales son Imperva (fundada en 2002) e IBM Guardium (fundada en 2002). La tecnología original consistía en un rastreador de red puro, pero rápidamente se incorporó a los controladores del kernel del servidor de bases de datos para rastrear la actividad local. Los principales obstáculos tecnológicos son:

• Actividad Cifrada: Es imposible examinar los paquetes de red entre el cliente y el servidor de la base de datos cuando la actividad está cifrada. El problema es grave, ya que, incluso si una base de datos no requiere cifrado de red, aceptará solicitudes para cifrar las conexiones por defecto. Esto significa que solicitar una conexión cifrada permite a un atacante eludir la solución.
  
  Para algunas bases de datos, las soluciones pueden utilizar un enfoque de intermediario (man-in-the-middle) con la clave de cifrado de la base de datos. Descifran y vuelven a cifrar el tráfico en ambas direcciones. Este método tiene varias limitaciones, pero la más grave es que no funciona con la actividad local (véase más adelante).
• Actividad Local: Como rastreador de red, una solución no puede detectar el tráfico interno del servidor de bases de datos. Detectar el tráfico local es vital porque los administradores de bases de datos (DBA) suelen conectarse localmente y algunas aplicaciones se ejecutan localmente. Las conexiones locales también son un vector de ataque común para los hackers que penetran en el servidor de bases de datos. Por ejemplo, todos los ataques de ransomware de doble extorsión violan la base de datos y cifran los archivos de datos. Esto significa que los ataques provienen del servidor de bases de datos y son invisibles para un rastreador.
  
  Para capturar la actividad local, las soluciones de captura de paquetes instalan un controlador de kernel en el servidor de bases de datos. Más allá de los problemas de estabilidad, esto plantea tres desafíos principales: (1) enviar todo el tráfico local al dispositivo de la solución requiere un ancho de banda de red significativo y, a menudo, requiere una tarjeta de red dedicada; (2) el controlador de kernel no puede cifrar/descifrar toda la actividad y, por lo tanto, la actividad cifrada local es invisible para la solución; y (3) bloquear la actividad es un desafío importante (véase más adelante).
• Actividad Interna: Las bases de datos son máquinas complejas con un universo interno completo. Por ejemplo, pueden ejecutar internamente cualquier cosa, desde breves scripts ad hoc hasta programas completos. Esto dificulta considerablemente la seguridad, ya que es fácil ejecutar un pequeño programa dentro de la base de datos que parece inofensivo, pero que realiza actividades maliciosas. Sin visibilidad de lo que sucede dentro de la base de datos, es imposible considerarla segura. Sin embargo, la actividad interna es algo que las tecnologías de captura de paquetes nunca pueden detectar.
• Actividad de Bloqueo: Algunos clientes desean bloquear, no solo informar, alertar e investigar. Existe una diferencia enorme en las propuestas de valor, tema que se tratará en otro artículo. Pero cuando se trata de bloqueo, las soluciones de captura de paquetes plantean un dilema único a sus clientes.
  
  La dificultad no radica tanto en las conexiones de red remotas, sino en las locales. El controlador del kernel que captura la actividad local suele operar en uno de dos modos: (1) enviar la actividad al dispositivo y esperar una respuesta antes de permitir el paso del paquete. Esto crea una latencia imposible en la comunicación, y (2) enviar el paquete y, si posteriormente se recibe una decisión de bloqueo, desconectar la sesión. Ninguna de las dos opciones es buena, y ambas reducen el valor que los clientes esperan de la funcionalidad de bloqueo.

En resumen: Las soluciones de segunda generación no son ideales, pero solían ser lo mejor que podíamos esperar. Con una compleja multitud de vulnerabilidades y limitaciones, ofrecen un nivel mínimo de seguridad y se dirigen principalmente a un público que busca el cumplimiento normativo. Sin embargo, ahora existe una tecnología mejor, y es hora de actualizarse.

Captura de Motor SQL de 3ra Generación

A finales de la década de 2000, se realizaron varios intentos para superar el obstáculo de la visibilidad (como Hedgehog e IDB). El más exitoso fue la Captura de Motor SQL que elegimos para Core Audit. Esta tecnología se basa en recursos internos de bases de datos que permiten a la solución capturar todo lo que pasa por el motor SQL. Esto se hace sin auditoría nativa y con una sobrecarga inferior al 3%.

La clave reside en la recopilación de microfragmentos de información en memoria a alta velocidad. Estos fragmentos se ensamblan posteriormente en el servidor de auditoría para formar registros de auditoría completos. Este tipo de captura evita la E/S de disco y es paralela a la transacción, por lo que no la ralentiza. La recopilación de microfragmentos disponibles elimina la necesidad de buscar información adicional en la base de datos, lo que permite que todo funcione a una velocidad increíble.

La tecnología de 3.ª generación elimina la disyuntiva entre visibilidad y rendimiento que afecta a la 1.ª y 2.ª generación. Por eso la utilizamos en Core Audit. Proporciona capacidades esenciales requeridas por el panorama de seguridad que las herramientas de primera y segunda generación no pueden alcanzar por diseño:

• Visibilidad: La 3.ª generación analiza las sentencias SQL a medida que fluyen a través del motor SQL. En otras palabras, ve las sentencias SQL cuando la base de datos las ve. Esto significa que ve la actividad cifrada, la actividad local, la actividad interna y todo lo demás que ejecuta el motor SQL.
• Rendimiento: Dado que la base de datos ya se encargó de la parte pesada de descifrar el tráfico y analizar los paquetes, esta captura solo necesita extraer la sentencia SQL. Esto implica un consumo mínimo de CPU y red. Además, la integración no utiliza auditoría nativa, por lo que la base de datos no realiza ninguna tarea adicional para recopilar, procesar o gestionar la información. La base de datos funciona exactamente como de costumbre en un modo de ejecución optimizado, pero activa pequeños eventos que la 3.ª generación puede convertir en un flujo de auditoría completo.
• Bloqueo: Al evaluar las reglas de bloqueo de SQL en una extensión del motor de base de datos, la 3.ª generación amplía la funcionalidad de seguridad integrada de la base de datos, proporcionando una función de bloqueo personalizada en el motor de base de datos.

Limitaciones: dado que la tecnología se ejecuta en la máquina de la base de datos, requiere instalación en el servidor de la base de datos. Esto significa que esta solución no puede utilizarse en entornos donde el cliente no tiene control sobre su propia base de datos, como ciertos entornos en la nube. En estos entornos, la 3.ª generación debe «rebajar» para utilizar otros mecanismos, como la captura de 2.ª generación.

La Paradoja de la Seguridad en la Nube

La seguridad de las bases de datos en la nube, tal como existe hoy en día, es un ejercicio de disonancia cognitiva. Por un lado, al ceder el control de la infraestructura, inevitablemente se cede el control de la seguridad. Por otro lado, usted es legal y moralmente responsable de la seguridad de sus datos, ya que el proveedor de la nube es responsable de todo menos de eso. Esa es la paradoja: eres responsable de la seguridad, pero sin control.

Si utiliza una DBaaS (Bases de Datos como Servicio) completamente administrada (como AWS RDS o Azure SQL), a menudo se ve obligado a retroceder a lo que el proveedor de la nube le permite hacer con su base de datos. Actualmente, esto implica seguridad de primera generación. Sin embargo, el problema con DBaaS es más fundamental que el control de la actividad, ya que el proveedor de la nube tiene acceso que usted no puede administrar ni ver. Desde su personal de administración de bases de datos (DBA) hasta el almacenamiento, las copias de seguridad e incluso el acceso al servidor, no puede esperar una seguridad rigurosa sin tener visibilidad y control.

En DBaaS, no tiene control sobre su servidor de bases de datos, lo que significa que no puede usar seguridad de tercera generación. Podría usar una versión parcial de segunda generación que funcione únicamente como un rastreador de red. Sin embargo, esto crea un enorme vacío sobre lo que sucede en la máquina, en las rutas de red que no controla, por no mencionar lo que se ejecuta internamente en la base de datos. Con una cobertura de segunda generación tan limitada, se ve obligado a recurrir a las capacidades de primera generación de su proveedor de la nube.

Si bien DBaaS (p. ej., AWS RDS, Azure SQL) ofrece ventajas operativas, crea una «caja negra de seguridad». Esto forma parte del coste de migrar a un servicio totalmente gestionado. La forma más sencilla de recuperar el control en la nube es migrar a IaaS (p. ej., AWS EC2, Azure VM). Esto le permitirá utilizar soluciones de tercera generación. Para datos de alta sensibilidad, el sector está volviendo a IaaS o incluso a las instalaciones locales.

La oferta de nube más reciente es sin servidor, lo que, obviamente, cede aún más control a cambio de ventajas operativas. En este modelo, comparte la base de datos con innumerables personas. No solo no tiene control, sino que incluso el proveedor de la nube tiene un aislamiento limitado entre usted y los demás. Este aislamiento depende exclusivamente de los controles de seguridad del software de la base de datos. Si hay un error en los controles internos de la base de datos, las barreras desaparecen y las empresas quedan expuestas a los datos de otros. Se recomienda encarecidamente no almacenar datos confidenciales en entornos sin servidor.

Usar DBaaS (o sin servidor) es una decisión de conveniencia, no de seguridad. Puede ser válido para algunos datos en algunas organizaciones, pero hasta que los proveedores de la nube ofrezcan visibilidad de tercera generación en DBaaS, la primera generación que ofrecen actualmente es la mejor opción. Migrar a una nube gestionada sigue siendo un riesgo calculado: cuanto más control cede, más sacrifica una seguridad profunda por facilidad operativa y aumenta su responsabilidad. Con suerte, con el tiempo y según la demanda de los clientes, los proveedores de la nube ofrecerán un mejor control, visibilidad y transparencia sobre lo que sucede en sus entornos.

Reflexiones Finales

Si bien las soluciones y tecnologías más recientes ofrecen muchas más capacidades, este artículo se centró en los requisitos más básicos: la captura y el procesamiento de datos. Si bien son obvios e ineludibles, las tecnologías antiguas no ofrecen ni siquiera estos aspectos esenciales.

La seguridad de la información se centra en los datos. Durante años, la industria ha estado obsesionada con los antivirus y las herramientas perimetrales. Si bien estos tienen su importancia, debemos preguntarnos: ¿cómo es que la seguridad de la información se centró más en firewalls y endpoints que en la protección de la información? ¿Cómo es que no invertimos ni actualizamos tecnologías antiguas y obsoletas, directamente responsables de la protección de nuestros datos?

Quizás solo busque una casilla de verificación de cumplimiento, y su infraestructura tecnológica actual sea suficiente para aprobar una auditoría. Sin embargo, tenga en cuenta que los requisitos de las auditorías evolucionan y que la tecnología antigua no las superará indefinidamente. Y lo que es más importante, recuerde que el cumplimiento no es seguridad, y una brecha de seguridad es un evento mucho más devastador que una auditoría fallida. ¿No sería prudente obtener seguridad real por el mismo precio que paga actualmente por una casilla de verificación de cumplimiento?

Proteger los datos es el requisito fundamental de nuestro oficio. Quedarse atrás con soluciones heredadas, costosas y que ofrecen visibilidad parcial nunca fue buena idea. Con las amenazas modernas, no proteger los datos ya no es una opción. Las tecnologías que necesita están disponibles ahora mismo. Puede proteger sus datos hoy mismo. La auditoría es una barrera de seguridad que ni siquiera lo detiene. Si su tecnología de defensa no puede protegerlo, no está «seguro»; simplemente tiene suerte. Al menos por ahora. Actualícese a una solución moderna de seguridad de bases de datos y controle su futuro. Es hora de ponerse al día.