Todos los ataques tienen el mismo destino: los datos de la base de datos. Sin embargo, el 99 % de la actividad de la base de datos se origina en una única cuenta de servicio de la aplicación. Entonces, ¿cómo se compara el control de la actividad de la base de datos con el control de la actividad de la aplicación?

La seguridad centrada en los datos controla la actividad que afecta a los datos. Esta defensa se implementa de adentro hacia afuera, como armar una muñeca matrioska o añadir capas de cebolla. El punto de partida son los datos, es decir, la base de datos. Esto también tiene sentido, ya que, independientemente de su ruta, un ataque siempre terminará en la base de datos con una credencial comprometida, abuso de privilegios, una inyección SQL, etc.

Sin embargo, existe una brecha de visibilidad. A pesar de ver toda la actividad, la base de datos no tiene el contexto completo de la mayor parte. Para la base de datos, la mayor parte de la actividad se origina en una entidad monolítica, la aplicación, que encapsula a cientos o miles de usuarios humanos individuales. Además, la base de datos desconoce qué hizo el usuario final para activar el acceso a los datos. Solo sabe que alguien hizo algo que desencadenó una consulta.

Así, mientras que la base de datos puede verlo todo, la aplicación añade otra capa de visibilidad invaluable. Comparemos el Control de Actividad de la Base de Datos (DAC) y el Control de Actividad de la Aplicación (AAC): dos sistemas independientes, cada uno valioso por sí mismo. Juntos son más potentes, pero ¿en qué se diferencian y qué defensas ofrecen?

Para comparar eficazmente el DAC y el AAC, examinaremos los métodos de captura modernos de tercera generación, que son la vanguardia de esta tecnología. Utilizan agentes ligeros con visibilidad extrema y capacidades de procesamiento fuera del servidor.

Una Cuestión de Lenguaje y Riesgo

Las bases de datos se comunican en el lenguaje de los datos: tablas y columnas. Al considerar el acceso a los datos, puede obtener una protección integral para todos sus datos. Las aplicaciones se comunican con los usuarios finales y las páginas URL en el lenguaje del negocio, pero también con cada SQL que ejecutan. Las aplicaciones conectan a personas reales que realizan transacciones comerciales con el lenguaje de los datos de la base de datos.

Al operar en la capa de aplicación, se obtiene la ventaja de usar términos comerciales, pero se pierde la capacidad de proteger fuera de la aplicación. Al descender a la capa de base de datos, ocurre lo contrario: se obtiene el control sobre todas las rutas de acceso a los datos, pero se pierde el contexto de la aplicación.

Si su seguridad se centra en los datos, la defensa de bases de datos es la opción obvia. Se trata de un enfoque integral con una defensa potente y completa. La exposición de sus datos se limitará a unos pocos ataques a las aplicaciones que podrían no detectarse a nivel de base de datos, como el scraping de datos mediante BOLA (Autorización a Nivel de Objeto Roto). Sin embargo, esa exposición probablemente sea mucho menor que la exposición derivada de no contar con un control de actividad de la base de datos (DAC). Solo DAC puede cubrir vectores de ataque críticos, como cuentas de administrador de bases de datos (DBA) mal utilizadas o comprometidas, conexiones locales dentro del servidor y más.

Sin embargo, si su seguridad requiere el lenguaje de la empresa, la elección entre cobertura y profundidad es difícil. AAC le ofrecerá las capacidades que desea, pero sus datos estarán expuestos a vectores de ataque críticos que eluden la aplicación. AAC solo puede ser su defensa inicial si todos los accesos a sus datos se realizan a través de la aplicación y cree que cuenta con las medidas suficientes para proteger las rutas de datos que no pertenecen a la aplicación.

La cuestión del lenguaje puede ser una cuestión de personal y habilidades, más que de lo que impulsa los resultados que necesita. Si cuenta con administradores de bases de datos (DBA) en su equipo de seguridad, es posible que prefiera la seguridad de las bases de datos, y un equipo de seguridad más centrado en las aplicaciones optará por protegerlas. Sin embargo, los recursos también son una cuestión de gestión: para la seguridad de las bases de datos, trabajará con el equipo de DBA, y para la seguridad de las aplicaciones, con el equipo de aplicaciones.

Por lo tanto, si quiere decidir qué es más vital para usted, el primer paso es decidir qué es más importante: los recursos con los que cuenta o su perfil de riesgo. Si es su riesgo, entonces debe elegir entre vulnerabilidades de aplicaciones más “difíciles de capturar”, como BOLA y XSS, y amenazas directas a bases de datos, como cuentas de DBA y acceso a bases de datos locales.

La Perspectiva de la Base de Datos: La Verdad Última

El Control de Actividad de la Base de Datos es la clave definitiva. Opera al final de la cadena de ejecución, capturando el SQL sin procesar que llega al motor. Si hay acceso a los datos, siempre lo verá aquí, sin lugar a dudas.

La Ventaja de la Visibilidad Total

El control de la actividad de la base de datos proporciona una visión integral de todos los accesos, algo con lo que la seguridad de la aplicación no puede competir. Detecta:

• Abuso administrativo: La actividad del administrador de bases de datos (DBA) siempre elude la aplicación y puede usar su acceso para modificar o robar cualquier dato.
• Robo de credenciales de DBA: Cuando una cuenta de DBA se ve comprometida, es tan grave como si el DBA decidiera abusar de sus privilegios.
• Acceso directo al sistema operativo: Un atacante obtiene acceso de shell al servidor de la base de datos y se conecta mediante una conexión local (una tubería, memoria compartida o un socket). Es un vector de ataque común que se produce en todos los ataques de ransomware de doble extorsión.
• Lógica interna del motor: Cuando una aplicación llama a un procedimiento almacenado o un disparador, el acceso a la tabla no es visible. Es código que se ejecuta dentro de la base de datos. Solo la tecnología DAC moderna ve las capas subyacentes, incluidos los accesos a las tablas que ocurren dentro del motor.

El Contexto Faltante

La debilidad del control de actividad de bases de datos (DAC) puro reside en la falta de contexto. Si una cuenta de aplicación comienza a recuperar registros, el DAC sabe qué está sucediendo, pero desconoce quién lo activó ni qué hizo. Sin ese contexto, la recuperación legítima de datos y la exfiltración maliciosa de datos pueden parecer muy similares.

Dependiendo del ataque, un acceso malicioso y uno válido no siempre son idénticos. Por eso, el DAC puede detectar un número significativo de vulnerabilidades de aplicaciones. Sin embargo, existen límites a la capacidad de visión interna del DAC.

Veamos un par de ejemplos:

En el caso de una inyección SQL, la aplicación envía un SQL inusual a la base de datos. Se trata de un SQL que la aplicación nunca envía de forma nativa, y en un buen motor de anomalías de actividad de bases de datos, resulta muy llamativo.

Sin embargo, en un ataque BOLA, la aplicación envía los mismos SQL que normalmente. La única diferencia es que envía una cantidad significativamente mayor. Ese «volumen extra» de una SQL específica puede destacarse en un análisis de anomalías, pero solo si se trata de un pico inusual. Si la aplicación consulta habitualmente entre 5000 y 10 000 de estas vistas en una hora, y un scraping de BOLA añade 2000, es probable que el ataque pase desapercibido. Sin embargo, si la aplicación normalmente tiene 100 de estas consultas, esas 2000 adicionales activarán la alarma.

La Perspectiva de la Aplicación: Usuarios Reales y Acciones

El Control de Actividad de Aplicaciones (AAC) no se centra realmente en el SQL final, sino en la perspectiva del usuario final: quién es, desde dónde se conectó, en qué página se encuentra, etc. También ve el SQL, pero conecta la información entre lo que hizo un usuario y el SQL subyacente enviado a la base de datos.

Para aclarar, no estamos hablando de un WAF, que es una herramienta de control superficial que observa desde fuera. El Control de Actividad de Aplicaciones que estamos analizando monitoriza lo que sucede dentro de la aplicación, desde que un usuario accede a una URL hasta que el SQL se envía a la base de datos.

La Ventaja del Contexto

Al ubicarse dentro del entorno de ejecución de la aplicación (como la JVM), AAC captura información que la capa de base de datos nunca ve:

• Contexto de usuario: el usuario que inició sesión en la aplicación y su dirección IP.
• Contexto de aplicación: las páginas específicas de la aplicación y demás jerga a nivel de aplicación que permite a los equipos de seguridad hablar el lenguaje del negocio en lugar del lenguaje de la base de datos (tablas y columnas).
• Significado empresarial: identificar, por ejemplo, patrones de «scraping» o «crawling» (BOLA/IDOR). Un usuario que consulta un solo perfil es normal, mientras que consultar 5000 perfiles por minuto constituye una infracción. Incluso si cada consulta SQL individual es perfectamente válida, el comportamiento del usuario no lo es.

¿Es RASP?

Tanto el Control de Actividad de Aplicaciones (AAC) como RASP operan en la aplicación durante la ejecución. Sin embargo, AAC está diseñado específicamente para la monitorización con un impacto mínimo y una implementación sencilla, mientras que RASP está diseñado para la protección en tiempo real, con todos los beneficios y riesgos que conlleva.

A continuación, se presentan algunas diferencias clave:

• Objetivos y arquitectura: RASP busca mejorar la seguridad de las aplicaciones bloqueando la actividad sospechosa desde dentro. El objetivo principal de AAC es recopilar y analizar la actividad de la aplicación. Por lo tanto, RASP debe generar una imagen clara de la actividad y analizarla dentro de la aplicación en línea (como parte de la transacción). AAC solo captura eventos sin procesar y transfiere asincrónicamente la correlación y el análisis a otra máquina. AAC puede proporcionar un bloqueo simple en la aplicación, pero los análisis complejos solo se entregan como alertas casi en tiempo real.
• Rendimiento y estabilidad: AAC es significativamente más ligero y rápido. RASP debe ejecutar mucho más código dentro de la aplicación para lograr sus objetivos de protección. Ese código pesado de RASP ralentiza el proceso y aumenta el riesgo, mientras que en AAC, el trabajo pesado y complejo ni siquiera se realiza en la misma máquina que la aplicación.
• Riesgo e implementación: Si bien es posible, las implementaciones de AAC no suelen alterar el comportamiento de la aplicación, mientras que en RASP ese es el objetivo principal. Un falso positivo en AAC se traduce en una falsa alerta, pero en RASP, significa una interrupción de la actividad de producción. AAC también se implementa a nivel de infraestructura (por ejemplo, argumentos de la JVM), sin necesidad de modificar el código fuente de la aplicación ni la lógica de compilación. Ni siquiera necesita acceder al código fuente y funciona igual de bien con software estándar.

La CAA proporciona una visibilidad profunda sin las desventajas de usar RASP. Sin embargo, RASP es una tecnología de prevención en tiempo real integrada en la aplicación, con la que la CAA no intenta competir.

El Terreno Común

Tanto la base de datos como la aplicación coinciden en una cosa: las SQL. Se trata de lo que la aplicación envía a la base de datos y lo que esta recibe de ella. Si lo que te interesa es a qué tabla se accedió, puedes verlo tanto en DAC como en AAC.

Para ser precisos, en la base de datos verás todas las SQL, no solo las de la aplicación. Por lo tanto, si te interesa saber a qué datos se accedió, la base de datos es la ganadora indiscutible. Obtendrás una visión más amplia y completa que la de la aplicación (por ejemplo, la actividad del administrador de bases de datos) y podrás ver con mayor profundidad la actividad interna de los procedimientos almacenados.

Sin embargo, si solo te interesa la actividad de la aplicación, AAC puede proporcionar un contexto completo de la aplicación, mostrando el usuario final real, la URL y más. De hecho, en AAC, las SQL no son el punto focal principal. Dado que puedes analizar el comportamiento del usuario desde una perspectiva empresarial, el acceso real a los datos a menudo se considera un mero efecto secundario de realizar una transacción comercial.

Expansión de AAC: el Lado del Cliente

El Control de Aplicaciones puede extenderse para controlar lo que sucede dentro del navegador web del usuario final. Al inyectar un pequeño fragmento de JavaScript en las páginas HTML, las soluciones avanzadas de control de la actividad de las aplicaciones pueden «ver» lo que hacen los usuarios.

La seguridad del cliente web ofrece visibilidad de la actividad del usuario final y de las partes de la aplicación que se ejecutan en el endpoint. También mitiga los ataques del lado del cliente, como XSS. Si bien es útil, se aleja de la base de datos y sus SQL, por lo que queda fuera del alcance de este documento. Sin embargo, mencionaremos algunas capacidades para explicar otras ventajas del uso de AAC:

• AJAX: Al supervisar o bloquear las interacciones de la aplicación cliente con otros servidores, puede detectar y bloquear el Cross-Site Scripting (XSS).
• Exfiltración de datos del usuario: Al detectar o prevenir acciones del usuario final, como copiar e imprimir, puede mitigar la extracción de datos.
• Clics: Las aplicaciones modernas utilizan código del lado del cliente para interactuar con el usuario. En estas aplicaciones, supervisar la interacción del usuario con la aplicación puede proporcionar visibilidad clave sobre su comportamiento.
• Protector de pantalla: Puede habilitar un protector de pantalla integrado en la aplicación o un tiempo de espera de página, lo cual es útil cuando no tiene control sobre los endpoints.

El control del lado del cliente es una potente expansión de la AAC, que le permite llegar hasta el endpoint. Esta es la tercera y más externa capa de la seguridad centrada en datos, fuera del servidor de aplicaciones (capa intermedia) y la base de datos (capa más interna).

Detección de Anomalías: la Defensa Poderosa

Configurar defensas declarativas contra infracciones específicas es eficaz para algunos vectores de ataque. Sin embargo, con miles de millones de actividades tanto en la base de datos como en la aplicación, a menudo se necesita una herramienta más potente.

Las anomalías detectarán cuándo algo no funciona correctamente. Le alertarán cuando el perfil de comportamiento cambie y deba prestar atención.

A continuación, se muestran algunos ejemplos y su aspecto en la base de datos y la aplicación posteriormente:

Tipo de Anomalía	Perspectiva de la BBDD	Perspectiva de la Aplicación
Una Nueva Construcción SQL	Una posible inyección SQL desde la cuenta app1 en el servidor1 (solo se identifica la cuenta app).	Posible inyección SQL del usuario John.Doe desde la IP 10.2.1.117 (identificar al usuario final).
Conexión Inusual	DBA1 se conectó desde una dirección IP diferente, 10.6.2.61 (usuarios directos de la base de datos)	El usuario John.Doe se conectó desde una dirección IP diferente, 10.7.2.35 (conexiones de la aplicación del usuario final).
Actividad Inusual	DBA2 está accediendo a una tabla a la que no había accedido antes. (según los datos)	John.Doe está accediendo a una URL a la que no había accedido antes. (según la página de la URL)
BOLA / IDOR	Este SQL se ejecutó con más frecuencia de lo habitual (SQL y número de ejecuciones de filas).	John.Doe accedió a esta URL con más frecuencia de lo habitual. (Recuento de accesos a la API del usuario final)

El Enfoque Híbrido

Una tendencia común en la industria es añadir contexto de aplicación a la actividad de la base de datos. Si bien se trata de una adaptación inteligente, es más bien una solución provisional en comparación con un AAC real. A continuación, se explica:

Una solución adecuada de Control de Actividad de Aplicaciones (AAC) puede ver lo que sucede en cualquier parte de la aplicación, desde el acceso del usuario a una página hasta las sentencias SQL enviadas a la base de datos. En el contexto de un enfoque híbrido, también se puede considerar que AAC añade las sentencias SQL de la aplicación a una vista completa de la misma. Esto contrasta con el enfoque híbrido, que añade un contexto mínimo de la aplicación a las sentencias SQL. En otras palabras, AAC ofrece mucho más que solo contexto con las sentencias SQL.

DAC ofrece una cobertura completa, que va más allá de la aplicación. Esa es su fortaleza. Si necesita controlar la aplicación, AAC es una opción mucho mejor.

Entonces, ¿de dónde proviene el enfoque híbrido? Proviene de proveedores que no tienen AAC y que intentan ofrecer una solución a la falta de visibilidad de los clientes. Es una solución que funciona para algunas aplicaciones, enriqueciendo la información de la base de datos con un poco de contexto.

Sin embargo, si considera valioso extraer el contexto de la aplicación al DAC, un AAC puede ayudarle fácilmente a realizar ese enriquecimiento. Es solo una pequeña parte de sus capacidades.

Rendimiento y Visibilidad: Monitoreo a Escala

Históricamente, el control profundo de la actividad era imposible debido a su impacto en el rendimiento. «No podemos activar la auditoría porque la sobrecarga bloquearía la base de datos/aplicación». Esto era cierto en la era de la auditoría nativa de primera generación. Más tarde, en la era de la captura de paquetes de segunda generación, el argumento se convirtió en «Es imposible obtener ese nivel de visibilidad». Sin embargo, es posible, y las tecnologías de captura modernas de tercera generación eliminaron la disyuntiva entre rendimiento y visibilidad al aprovechar el motor SQL.

Captura de Base de Datos No Intrusiva

Las soluciones DAC modernas ya no dependen de pesados ​​registros de auditoría nativos ni de capturas masivas de paquetes (1.ª y 2.ª generación). En su lugar, obtienen los datos que necesitan directamente del motor SQL. Al aprovechar el procesamiento ya realizado por la base de datos, esta captura puede extraer solo los datos necesarios con menos del 3 % de sobrecarga. No notará un impacto significativo, incluso en entornos OLTP de alto volumen que procesan decenas de miles de transacciones por segundo.

La captura completa con un impacto mínimo es la razón por la que elegimos la tecnología de captura de 3.ª generación para impulsar Core Audit. Pero ¿cómo funciona la «magia»?

Primero, expliquemos la visibilidad. El motor SQL reside debajo de la pila de red de la base de datos y es indiferente al mecanismo de transporte (cifrado, conexión local, conexiones remotas). Puede ver por igual la actividad externa e interna. Si la base de datos ejecuta una sentencia SQL, esta pasa por el motor SQL. Esto significa que ver lo que sucede aquí le brinda visibilidad de toda la actividad de la base de datos.

El motor SQL también es donde reside la auditoría nativa (1.ª generación). Entonces, ¿por qué la tercera generación es tan ligera mientras que la primera es tan pesada? La clave está en el procesamiento adicional. La auditoría integrada de la base de datos es lenta porque la base de datos debe realizar trabajo adicional. Necesita recopilar más información para los registros de auditoría y almacenarla. Necesita buscar el usuario, el programa, el SQL, etc. También necesita escribir en un archivo o, peor aún, en una tabla de la base de datos. La tecnología de tercera generación extrae la información sin procesar, pero realiza el resto del trabajo fuera del servidor de la base de datos.

Al transferir asincrónicamente la correlación, el procesamiento, el almacenamiento y otras tareas a otra máquina, una solución de tercera generación puede evitar el «efecto observador» que ralentiza la base de datos y ofrecer la «magia» de la visibilidad completa sin la sobrecarga de rendimiento.

Monitoreo de Aplicaciones en Tiempo de Ejecución

En cuanto a las aplicaciones, las pilas de aplicaciones modernas ofrecen capacidades únicas diseñadas para extraer información con un impacto mínimo. En entornos Java, por ejemplo, se puede añadir un agente Java a la línea de comandos de inicio de la JVM. Este añade enlaces en tiempo de ejecución que recopilan información de eventos sin procesar con un impacto mínimo. Al igual que con DAC, la clave reside en delegar la pesada tarea de correlación, procesamiento y análisis a otro servidor de forma asíncrona.

El uso de las capacidades integradas en la infraestructura implica que no es necesario modificar el código de la aplicación ni acceder a él. La pila Java cuenta con características específicas que permiten la recopilación de datos con un impacto mínimo. Invisible para el ojo humano, a la vez que ofrece visibilidad completa al personal de seguridad.

¿Vale la Pena?

Implementar un agente de base de datos, un agente Java o cualquier instalación en servidores de producción conlleva riesgos operativos. Entonces, ¿el esfuerzo justifica el valor que ofrecen?

Respondamos desde varias perspectivas:

1. Es la única manera de obtener la visibilidad necesaria para proteger sus sistemas. Si no se ejecuta en la máquina, no puede ver lo que sucede dentro. «Sin agente» es una palabra de moda que no funciona: ya sea porque todavía se necesita un agente o porque no se obtiene suficiente visibilidad. Sin visibilidad, no se pueden tener controles efectivos y se terminará con una solución parcial.
2. Es mucho más fácil y seguro de lo que parece. La clave para lograr agentes estables es la previsibilidad. Los agentes con pocas rutas de ejecución son más fáciles de probar y garantizan su fiabilidad y estabilidad. Esto significa que los agentes «buenos» son pequeños, simples y con una funcionalidad mínima, descargando todo el trabajo complejo a otra máquina. Se miden en kilobytes, no en megabytes.
3. Las alternativas son mucho peores. Ya sea que implemente un WAF, una solución de auditoría nativa de primera generación o un rastreador de paquetes de segunda generación, son más complicados de instalar, configurar, ajustar y poner en funcionamiento. El WAF, por ejemplo, requiere pruebas exhaustivas para garantizar que no bloquea la actividad legítima. Los agentes locales de los analizadores de paquetes involucran controladores de kernel y tarjetas de red adicionales que deben instalarse en la máquina de la base de datos.

Puntos Ciegos

Antes de lanzar el veredicto, repasemos algunos de los vectores de ataque mencionados:

Vector de Ataque	¿Visible para DAC?	Visible para AAC?
SQL Injection	Sí (SQL inusual)	Sí (SQL inusual)
BOLA / Scraping	Tal vez (volumen SQL inusual)	Sí (Comportamiento del usuario)
Robo de Credenciales / DBA no Autorizado / Acceso Local	Sí (Acceso a datos sospechosos)	No (omite la aplicación)
Inyección de Procedimiento Almacenado	Sí (Ejecución interna)	No (Solo ve la ‘Llamada’)
XSS	No (solo del lado del cliente)	Sí (Control del lado del cliente)

Tenga en cuenta que existen muchos otros vectores de ataque. Esta lista solo pretende ilustrar los tipos de ataques que cada tecnología puede abordar mejor.

El Veredicto

En primer lugar, debemos señalar que esta revisión comparó controles de actividad de bases de datos y aplicaciones de vanguardia. Las soluciones más antiguas con visibilidad o análisis más limitados probablemente generarán conclusiones diferentes.

En definitiva, los controles de actividad de bases de datos y aplicaciones son complementarios, y usar ambos sería ideal. Sin embargo, los presupuestos, el personal y el tiempo son limitados, y a menudo debemos elegir uno primero.

Nuestra recomendación dependerá del tipo de base de datos/pila de aplicaciones que desee proteger:

• Las «pilas tradicionales» se basan en arquitecturas integrales (monolitos) y bases de datos relacionales con numerosas funcionalidades, como Oracle o SQL Server.
• Las «pilas modernas» se basan en arquitecturas modulares (microservicios) y bases de datos nativas de la nube o NoSQL. Priorizan las API y los diseños distribuidos. Las pilas modernas se basan en arquitecturas modulares (microservicios) y bases de datos nativas de la nube o NoSQL. Priorizan las API y los diseños distribuidos.

Estos dos diseños de pila presentan perfiles de riesgo distintos y requieren enfoques diferentes. Obviamente, existen muchos factores intermedios, y usted debe determinar qué riesgo y enfoque se adaptan mejor a su entorno.

Pilas o Stacks «Tradicionales»

En una pila tradicional, comience con la base de datos.

El perfil de riesgo de una pila tradicional contiene vectores de ataque a la base de datos que no se pueden ignorar. Por ejemplo, una vulneración del servidor de la base de datos, el robo de credenciales y el abuso de privilegios. Las aplicaciones tradicionales también tienen pocas API, y la inyección de SQL es una exposición más probable que un ataque BOLA. Además, la rica base de datos abre la puerta a ataques creativos que explotan procedimientos, bloques anónimos y más.

Por lo tanto, en una pila tradicional, siga la física: la base de datos es el único lugar donde termina cada ruta de ataque.

1. Cobertura. No se puede proteger lo que no se ve, y estar en la ruta crítica de cualquier brecha es una prioridad fundamental que no se puede ignorar.
2. Riesgo: El Control de Actividad de la Base de Datos (DAC) aborda, en promedio, riesgos más significativos que el AAC. Estos son vectores de ataque que no se deben ignorar.
3. Cumplimiento: El control de la base de datos es fundamental para el cumplimiento. A los auditores les importa mucho más quién accedió a su información personal identificable que a qué URL se accedió.
4. La regla «de adentro hacia afuera»: Primero, se cierra la bóveda y, solo después, la ventana. La seguridad centrada en los datos construye defensas de adentro hacia afuera. Primero, se protege la base de datos, luego la aplicación y, finalmente, el endpoint. Omitir las defensas internas crea vulnerabilidades que no se pueden compensar externamente.

Estos cuatro puntos representan diferentes facetas de la misma realidad, pero todas son perspectivas importantes.

Pilas o Stacks «Modernos»

En un stack moderno, comience por la aplicación.

En estos entornos, la aplicación funciona esencialmente como un servicio de acceso a datos (a través de una API). Es una fuente de datos que alimenta a los usuarios u otras aplicaciones. Si bien no almacena los datos, es el principal punto de retransmisión. Como fuente de datos principal, estas aplicaciones merecen una prioridad de seguridad a nivel de base de datos.

Además, estos stacks suelen aprovechar bases de datos con funcionalidades limitadas. Bases de datos que, a menudo, están distribuidas (lo que dificulta su control), y que, en la nube (es decir, DBaaS), de todos modos no se tiene control.

Todo esto inclina el perfil de riesgo a favor de la aplicación. Además, se inclina hacia ataques a aplicaciones que tienen menos probabilidades de detectarse en la capa de base de datos. La base de datos subyacente sigue viendo todo el acceso a los datos, pero los patrones de actividad se vuelven demasiado ruidosos como para detectar un abuso de la lógica de la aplicación. El mismo SQL de ese mismo microservicio se ejecuta en muchas rutas de ejecución de aplicaciones diferentes y sin relación entre sí.

Reflexiones Finales

Hemos profundizado en la protección de la base de datos o la aplicación. Y, como saben, es fundamental proteger ambas. Así que, independientemente de su elección inicial, comiencen a planificar cómo construirán su seguridad de cara al futuro. Una pieza ahora, otra en seis meses, otra el año que viene. Construiremos este muro ladrillo a ladrillo. Pero si no empiezan a construirlo, no se construirá solo.

El perímetro no ofrece una protección que justifique su inversión. Es difícil justificar el valor de una defensa porosa. Así que, comiencen a centrarse en construir este muro. Es la única estrategia, y saben que deben hacerlo.

Actúen ahora, porque cuanto más esperen, más tiempo les darán a los atacantes para vulnerar sus defensas. Elijan la capa que represente su mayor riesgo y protéjanla hoy.