Introducción

Durante años, el mantra de la ciberseguridad se centró en el «perímetro». Los cortafuegos se erigían como murallas digitales de Adriano, el software antivirus patrullaba las puertas y los filtros de correo electrónico actuaban como centinelas vigilantes. Este enfoque se centraba en mantener alejados a los «malos» y ofrecía una sensación tangible de seguridad. Podíamos ver las defensas, observarlas en acción y sentir una apariencia de control.

Pero los ataques modernos del siglo XXI no funcionan así. Los hackers han tenido en cuenta estas cerraduras de las puertas principales y han aprendido a trepar por las ventanas. Al fin y al cabo, estas «ventanas» ofrecen un acceso mucho más fácil.

Pero el panorama digital sigue cambiando. El perímetro, que antes era una frontera aparentemente sólida, ahora es poroso, fragmentado y cada vez más irrelevante. Todo se ha interconectado tanto que las fronteras se han disuelto. La computación en la nube, el trabajo a distancia, la externalización y las integraciones de sistemas han difuminado las líneas hasta hacerlas desaparecer. Confiar únicamente en las defensas perimetrales hoy en día es como proteger un cofre del tesoro con la puerta principal cerrada con llave mientras todas las ventanas están abiertas de par en par.

Con el 90 % de las empresas informando de al menos un ataque en el último año, las olas golpean constantemente nuestro castillo de arena. Y con casi el 40 % de ellas vulneradas, el agua ya está entrando.

La fría y dura lógica: por qué la seguridad perimetral falla en la protección de sus datos

Las brechas de seguridad ya no son una cuestión de «si» ocurrirán, sino de «cuándo». Los titulares gritan esta verdad con alarmante regularidad. Los atacantes sofisticados eluden habitualmente incluso los perímetros más robustos y costosos. Atacan a las organizaciones más grandes y seguras del planeta. Lo hacen a través de:

• Ingeniería social: el factor humano sigue siendo el eslabón más débil. Los ataques de phishing inteligentes y las tácticas de manipulación social pueden engañar incluso a los empleados más vigilantes. Una vez dentro, tras el perímetro, los atacantes tienen vía libre.
• Amenazas internas: los empleados descontentos, los usuarios codiciosos o la pura malicia dentro de su organización representan un riesgo significativo y a menudo pasado por alto. Más del 20 % de las violaciones de datos son obra de actores internos y el perímetro no ofrece ninguna protección contra ellos.
• Explotaciones de día cero: estas vulnerabilidades previamente desconocidas en el software pueden ser explotadas incluso antes de que estén disponibles los parches. Las defensas perimetrales, centradas en las amenazas conocidas, son impotentes contra estos nuevos ataques.
• Ataques a la cadena de suministro: cada vez más, los atacantes se dirigen a proveedores externos menos seguros para acceder a sus objetivos principales. Su sólido perímetro pierde relevancia si un socio con acceso se ha visto comprometido.
• Configuraciones erróneas: los errores humanos son inevitables. Una regla de firewall mal configurada o un control de acceso demasiado permisivo pueden crear inadvertidamente grandes agujeros en sus defensas, lo que hace que su inversión sea inútil.
• Dispositivos inseguros: El trabajo remoto y el BYOD (traiga su propio dispositivo) significan que hay muchos dispositivos sobre los que no tiene control y que están en su red. Cualquiera que tenga acceso al ordenador doméstico de un empleado está conectado directamente a su red interna.

Pensar que su perímetro resistirá estas amenazas multifacéticas no solo es optimista, sino peligrosamente ingenuo. Es como creer que un foso detendrá a un enemigo decidido con alas.

El camino hacia la verdadera seguridad

Adoptar el enfoque centrado en los datos

Sabemos que la seguridad perimetral no es infalible. Cada semana vemos cómo se producen violaciones de seguridad en organizaciones. Somos conscientes de que una violación de datos es inevitable y solo es cuestión de tiempo. Sin embargo, seguimos confiando en el perímetro y realizando grandes inversiones en él.

La ilusión creada por la seguridad perimetral nos da una falsa sensación de tranquilidad. Sin embargo, la verdadera seguridad no reside en construir muros más altos, sino en proteger las joyas de la corona: sus datos. Eso requiere un cambio de paradigma hacia una seguridad centrada en los datos y una estrategia de defensa en profundidad.

Pasos preliminares: Estos son pasos fundamentales para establecer una base mínima para su seguridad. No detendrán ningún ataque moderno, pero ofrecen una buena base sobre la que empezar a construir.

• Conozca sus datos: localice dónde residen sus datos confidenciales, quién tiene acceso a ellos y cómo los utilizan. Esta visibilidad fundamental es el primer paso hacia una protección eficaz. No se pueden proteger datos si no se sabe dónde están ni quién los maneja. Empiece por las bases de datos y luego vaya avanzando hacia fuera. Core Audit puede ayudarle a obtener esta visibilidad tanto en sus bases de datos como en sus aplicaciones.
• Bloquee el acceso: desde las políticas de contraseñas hasta los privilegios mínimos, debe asegurarse de que los usuarios estén debidamente autenticados y solo tengan autorización para acceder a los datos necesarios para realizar sus tareas. Estos son pasos fundamentales en materia de seguridad, pero son insuficientes y no pueden detener a los atacantes. Debe hacer más.
• Cifrado: cifre los datos en tránsito y en reposo. Hoy en día, se trata de una medida de seguridad estándar, integrada en todas las pilas tecnológicas y fácil de habilitar. Aunque es vital, tampoco detendrá la mayoría de los ataques.

Control de actividades: El reto subyacente en la seguridad centrada en los datos es inspeccionar y proteger todas las actividades que acceden a los datos. Al inspeccionar todo (y hay miles de millones de actividades), lo que se ve en su mayor parte son actividades legítimas. Hay que aislar las pocas actividades potencialmente ilegítimas que hay entre ellas. Ahí es donde entran en juego el análisis de anomalías, el análisis forense proactivo y la prevención avanzada de actividades. Por eso son indispensables soluciones como Core Audit y Core Masking. El control de la actividad también es un requisito de todos los requisitos de cumplimiento, lo que reconoce su importancia vital.

• Seguridad de bases de datos: Más allá de lo mínimo imprescindible, debe emplear la supervisión de la actividad, el análisis de anomalías, el análisis forense proactivo y la prevención avanzada de actividades. Se trata de tecnologías especializadas diseñadas para proteger su sistema de bases de datos específico. Sin este tipo de defensas, no podrá detener ningún ataque actual. Core Audit es una solución esencial en esta tarea, ya que ofrece la protección más avanzada para sus bases de datos.
• Seguridad de las aplicaciones: siguiendo los datos desde la base de datos hasta la aplicación, emplee la supervisión de la actividad, el análisis de anomalías y el análisis forense proactivo a nivel de la aplicación. Se trata de variaciones de las tecnologías especializadas en bases de datos. Sin embargo, las hemos diseñado para bloquear su aplicación. Son complementarias al WAF, pero superiores, ya que miran dentro de la aplicación, no solo fuera. Core Audit es compatible con aplicaciones Java y Web Client Security para complementar las medidas de seguridad de la base de datos y mantener sus datos a salvo.
• Enmascaramiento de datos: Debe enmascarar los datos fuera de los sistemas de producción. Aunque hay otras formas de defenderlos, el enmascaramiento de datos es, con diferencia, la solución más fácil y rentable. El reto es garantizar que los datos enmascarados sean valiosos para las pruebas, el desarrollo u otros fines para los que están destinados. De lo contrario, eliminar la información confidencial no tiene sentido. Aquí es donde las capacidades de Core Masking se vuelven indispensables, ya que ofrecen una amplia gama de algoritmos que se adaptan a cada propósito.

El factor humano: Las soluciones necesitan personas que las operen. Sin personas que comprendan las tecnologías, sepan qué buscar y cómo responder, no se logrará la seguridad. Son las personas las que harán que su seguridad funcione.

• Forma a tu personal de seguridad: pasar de la seguridad perimetral tradicional a una centrada en los datos requiere habilidades adicionales. Las personas deben saber cómo es una inyección SQL y cómo reaccionar ante las alertas de actividades sospechosas. Las organizaciones pasan por un proceso de maduración a medida que pasan de limpiar virus y correos electrónicos no deseados a combatir las amenazas modernas. Esto requiere las soluciones adecuadas, formación, experiencia y arraigarlo en tu ADN de seguridad.
• Forma a tus administradores de bases de datos y aplicaciones: la seguridad centrada en los datos puede ser muy técnica y requerir que se base en los conocimientos especializados a nivel de dominio que ya existen en su organización. Contar con la participación de los administradores no solo consolidará el respaldo técnico que pueda necesitar, sino que también integrará la seguridad en toda la pila de TI.

Reflexión Final

Superar la mentalidad obsoleta centrada en el perímetro es inevitable. Es solo cuestión de tiempo. Sin embargo, requiere valor y voluntad para adoptar un enfoque más moderno y completo. Más aún, requiere reconocer que los muros fallarán y que debe cambiar su enfoque para proteger lo que realmente importa: sus datos.

Comience por proteger su base de datos. Ese es un primer paso importante y le ayudará a adoptar este cambio radical de mentalidad: pensar en sus datos. Incluso si, en este momento, no sabe qué son, dónde están, quién los utiliza o cómo. Ese es el comienzo de este nuevo viaje.

No deje que la ilusión del muro le lleve a una falsa sensación de seguridad. El coste de la inacción es mucho mayor que la inversión en una seguridad sólida centrada en los datos. Es hora de abandonar el castillo de arena y construir una verdadera fortaleza de datos desde dentro hacia fuera. Su negocio, sus clientes y su tranquilidad dependen de ello.

La seguridad centrada en los datos y los controles de actividad son el futuro de la seguridad. Es, por ejemplo, la única forma de proteger la nube, ya que esta no tiene perímetro. Sin embargo, con o sin perímetro, la seguridad centrada en los datos es el único método eficaz para protegerlos. Déjenos ayudarle a controlar sus datos. ¡Póngase en contacto con nosotros hoy mismo!

Una encuesta de Rubrik Zero Labs revela que el 90 % de los responsables de TI y seguridad sufrieron ciberataques durante el último año, y el 20 % informó de un ataque cada dos semanas de media.

Se trata solo de ataques, pero los ataques tienen consecuencias. El 30 % informó de brechas de datos en las instalaciones, el 28 % de brechas en la nube o SaaS y el 26 % de ransomware.

Y lo más alarmante es que esos son solo los que se conocen. Probablemente haya muchos más.

La única conclusión a la que puede llegar cualquier persona racional es que lo que sea que estés haciendo no está funcionando. No se trata de hacer más de lo mismo. Hay que hacer algo diferente. El camino actual se está desintegrando ante nuestros ojos. El 90 % de las empresas sufren ataques porque estos ataques tienen éxito. Las defensas son simplemente ineficaces y no funcionan. No hay otra forma de explicar estas cifras.

¿Qué puedes hacer?

En primer lugar, hay que aceptar que defender el perímetro es una batalla perdida. Es una batalla que debemos librar, pero que perderemos. Por lo tanto, no invierta demasiado en la defensa del perímetro. Desde la seguridad de la red hasta los puntos finales, los correos electrónicos, el AIM y las contraseñas, es una batalla que probablemente ya haya perdido muchas veces sin darse cuenta. No es que los atacantes hayan comprometido todas las defensas del perímetro, pero sí algunas de ellas. O tal vez los atacantes entraron por otra vía.

La realidad es que los atacantes penetran constantemente los perímetros de la mayoría de las empresas. Si no es desde el exterior, entonces desde un actor interno. En la encuesta de Rubrik, los empleados internos fueron responsables del 28 % de los ataques. Otras estimaciones los sitúan en torno al 20 %. Sin embargo, ya sean internos o externos, los atacantes encuentran la manera de entrar. No hay forma de detenerlo, solo de ralentizarlo.

La pregunta obvia es: «¿Qué podemos hacer?».

Una respuesta que escucho a menudo es «Nada». Solo hay que esperar la inevitable brecha. Está por llegar.

No me gusta esa respuesta y me niego a aceptarla.

La otra respuesta es la seguridad centrada en los datos. Significa centrarse en proteger los datos. Si no se puede evitar que los actores maliciosos penetren en la red, hay que proteger los datos de todo el mundo.

Dado que hay actores maliciosos que entran desde el exterior y amenazas internas desde el interior, todo el mundo es sospechoso. Tenemos que proteger los datos contra todo el mundo.

Las contraseñas pueden ser robadas, las personas suplantadas y los privilegios abusados. Hay una lista interminable de vectores de ataque, y la conclusión es simple: no se puede confiar en ninguna actividad. Hay que evaluar cada acceso a los datos. Todo es sospechoso.

Es una gran conclusión, pero ¿cómo se puede hacer?

Con miles de millones o billones de accesos al mes, no es un trabajo que pueda realizar una persona. Sin embargo, las tecnologías modernas pueden capturar y evaluar todos estos accesos para encontrar esa aguja en el pajar.

Esa afirmación suena demasiado buena para ser cierta, y en cierta medida lo es. Es una generalización, y los detalles son mucho más complicados. Pero sí. Es posible controlar toda la actividad de la base de datos y toda la actividad de la aplicación. Blue Core Research ha desarrollado una serie de tecnologías que pueden lograrlo. Póngase en contacto con nosotros para obtener más información.

¿Qué es una base de datos?

Una base de datos es una solución de software que almacena, manipula y recupera datos. Piensa en una hoja de cálculo de Excel, pero una base de datos opera a una escala mucho mayor. Una base de datos es como miles de hojas de cálculo de Excel, algunas con millones de filas, a las que acceden simultáneamente miles de personas. Para ser precisos, se trata de una base de datos relacional, pero las bases de datos relacionales son el tipo más común de base de datos y te dan una idea general.

Parece bastante complejo, pero por eso la tecnología es tan valiosa. Estas «hojas de cálculo» se denominan tablas y existen relaciones entre ellas. Por ejemplo, una tabla puede contener el nombre y la dirección de un cliente, mientras que otra tabla contiene más información sobre ese cliente. La segunda tabla hace referencia al cliente de la primera a través de un ID de cliente. Esa es la parte relacional de las bases de datos relacionales.

Para acceder a estos datos, debe utilizar un lenguaje llamado SQL. El SQL es un lenguaje similar al inglés que entienden las bases de datos. Es casi idéntico en todos los tipos de bases de datos. Permite a los usuarios consultar datos utilizando «select» o modificar datos utilizando «insert», «update» y «delete». Hay otra categoría de SQL llamada DDL. Los administradores utilizan los DDL para gestionar la base de datos, por ejemplo, para crear o eliminar tablas.

¿Quién utiliza la base de datos y cómo?

Escribir SQL no es demasiado difícil, pero no es habitual que las personas que trabajan con bases de datos conozcan SQL o lo utilicen. La mayoría de las personas utilizan aplicaciones que traducen lo que intentan hacer a SQL.

Por lo general, hay tres tipos de cuentas en las bases de datos:

• Los administradores de bases de datos, o DBA, son responsables de gestionar la base de datos. A menudo escriben SQL, pero también utilizan aplicaciones diseñadas para administradores. Estas facilitan ciertas operaciones al eliminar la necesidad de escribir SQL. Los DBA tienen acceso ilimitado a la base de datos y a los datos. Pueden acceder a cualquier cosa y cambiar lo que quieran. Además de las cuentas DBA individuales, los DBA suelen tener acceso a cuentas de base de datos privilegiadas especiales integradas. Por lo general, también tienen acceso al sistema operativo del servidor de la base de datos.
• Las cuentas de aplicación no son para personas reales. Los servidores de aplicaciones las utilizan para acceder a los datos de la aplicación. Los usuarios finales reales utilizan el software de los servidores de aplicaciones, y ese software envía SQL a la base de datos utilizando una cuenta de aplicación.
• Las bases de datos a veces tienen cuentas para analistas y otras personas que necesitan acceso directo a los datos. A veces escriben SQL, pero a menudo utilizan herramientas especiales para acceder a los datos.

El modelo de seguridad de bases de datos

Las bases de datos tienen dos mecanismos para dar acceso a los usuarios. Los «privilegios» otorgan a los usuarios derechos globales, como el derecho a leer cualquier tabla de la base de datos. Estos suelen ser para los administradores de bases de datos, a quienes se les otorgan derechos de superusuario. Los «permisos» otorgan a los usuarios acceso a tablas o columnas específicas. Estos son para todas las demás cuentas, a las que se les concede acceso solo a información concreta.

Por lo general, los privilegios y permisos se otorgan a través de un sistema o roles, en lugar de directamente a cada usuario. Un rol es un conjunto de privilegios y permisos que se pueden otorgar a los usuarios u otros roles.

La aplicación debe tener acceso a todos los datos y siempre tiene permiso para acceder a todo. La capa de seguridad que concede a cada usuario final acceso solo a algunos de los datos se encuentra dentro de la aplicación. Los servidores de aplicaciones realizan la autenticación y autorización de los usuarios finales. La lógica interna del servidor de aplicaciones se encarga de garantizar que los usuarios finales solo puedan acceder a lo que están autorizados a hacer. Desde la perspectiva de la base de datos, la aplicación tiene acceso a todos los datos.

Las fortalezas y los retos de la seguridad de las bases de datos

Puede habilitar fácilmente funciones de seguridad en las bases de datos, como el cifrado de datos en tránsito y datos en reposo. También puede activar reglas de política de contraseñas integradas. Más importante aún, la autenticación de bases de datos es muy madura, y es poco probable que alguien pueda conectarse sin un nombre de usuario y una contraseña válidos.

Sin embargo, el mayor problema es que la mayoría de las cuentas tienen acceso a todos los datos. Los administradores de bases de datos tienen acceso a todo debido a sus privilegios administrativos. La cuenta de la aplicación puede acceder a todo porque la aplicación lo necesita. Los analistas y otras cuentas pueden tener permisos más limitados, pero muchas veces también tienen acceso a la mayoría (si no a todos) los datos.

Esto supone un reto, ya que la forma en que utilizamos las bases de datos no se ajusta al modelo de seguridad de las mismas. No hay forma de limitar el acceso de los administradores de bases de datos o de las aplicaciones, y estas cuentas representan casi toda la actividad de la base de datos.

Amenazas a las bases de datos

Dado que las conexiones a la base de datos siempre utilizan usuarios y contraseñas válidos, las amenazas se limitan a las conexiones autenticadas. Las conexiones pueden provenir de usuarios reales o de alguien que se haga pasar por ellos. A continuación se muestra la lista de amenazas:

• Amenaza interna del administrador de bases de datos (DBA). Se trata de la amenaza de abuso de privilegios por parte de un administrador de bases de datos. Aunque los DBA suelen ser personas de confianza, su acceso sin restricciones los convierte en un riesgo para la seguridad.
• Compromiso de la cuenta del DBA. Se trata de una amenaza externa de que alguien robe las credenciales del DBA. Esto puede ocurrir, por ejemplo, a raíz de una violación de la seguridad del ordenador del DBA. También podría tratarse del robo de credenciales de una cuenta privilegiada compartida, como SYS o SA.
• Compromiso de la cuenta de la aplicación. Puede tratarse de una amenaza interna o externa. Se trata de obtener acceso a las credenciales de la aplicación. Podría ser un administrador o desarrollador de la aplicación con acceso a las credenciales (amenaza interna) o un agente externo que las haya obtenido de un archivo de configuración (amenaza externa).
• Compromiso de la aplicación. Puede tratarse de una amenaza interna o externa. Por ejemplo, explotar una vulnerabilidad en la aplicación (como una inyección SQL). También podría tratarse de desarrolladores que abusan de su acceso al código de la aplicación.
• Otro abuso o compromiso de cuentas. Al igual que la cuenta del administrador de bases de datos, otras cuentas de bases de datos pueden ser objeto de abuso por parte de sus legítimos propietarios o comprometidas por un agente externo.
• Acceso local. La mayoría de las bases de datos permiten conexiones no autenticadas desde cuentas específicas del sistema operativo en el servidor de la base de datos. Esto significa que obtener acceso a estas cuentas en el servidor de la base de datos le dará acceso a la base de datos. Incluso si dicho acceso está bloqueado, normalmente se puede habilitar o eludir.

Protección de una base de datos

Ahí es donde las cosas se ponen interesantes. Comenzaremos con las mejores prácticas más populares para proteger una base de datos. Esa orientación suele incluir:

• Seguridad de las cuentas. Identifique las cuentas inactivas y ciérrelas. Siga los principios de privilegios mínimos para las cuentas activas y habilite una política de contraseñas.
• Cifrado. Active el cifrado de los datos en tránsito y en reposo.
• Parches. Asegúrese de instalar el último parche de seguridad.
• Análisis de vulnerabilidades. Realice análisis de vulnerabilidades y solucione las que se detecten.

Aunque son importantes, ninguna de estas medidas aborda las amenazas a las bases de datos mencionadas anteriormente. No abordan ni una sola amenaza. Esto se debe a que los atacantes se han adaptado hace tiempo a las defensas estándar de las bases de datos.

Se necesita un nombre de usuario y una contraseña válidos para acceder a una base de datos, por lo que las medidas de seguridad de las cuentas no detendrán los ataques. El acceso tampoco implica rastrear paquetes de red o robar archivos, por lo que el cifrado no es útil. Por último, las bases de datos modernas rara vez tienen vulnerabilidades relacionadas con la autenticación, por lo que el análisis de vulnerabilidades y la aplicación de parches no se dirigen a estas amenazas.

Entonces, ¿cómo podemos proteger una base de datos?

La seguridad eficaz de las bases de datos aprovecha el control de la actividad. El control de la actividad combina medidas de detección y prevención que aplican la seguridad a nivel de sesión de la base de datos y de SQL. Soluciones como Core Audit le ayudarán a combatir estas amenazas reales.

Control de actividades

El control de actividades incluye auditoría de bases de datos, bloqueo avanzado de SQL, análisis de anomalías y análisis forense proactivo y reactivo. Aplica medidas de seguridad a las sesiones autenticadas que ejecutan actividades autorizadas.

Por ejemplo, las medidas para proteger las cuentas de DBA se centrarían en actividades que los DBA rara vez ejecutan. La detección podría alertar de DML (inserciones, actualizaciones y eliminaciones) o del acceso a datos confidenciales. Las medidas de detección más sencillas se aplicarían a nivel de sesión, inspeccionando los inicios de sesión fallidos y las fuentes de conexión, como los programas, las máquinas y las direcciones IP que utilizan los DBA para conectarse.

Las medidas preventivas para las cuentas de DBA podrían bloquear el acceso de los DBA a datos confidenciales. El bloqueo avanzado de SQL puede inspeccionar cada SQL y bloquear aquellos que acceden al esquema de datos. Otra medida preventiva para las cuentas de administrador de bases de datos es imponer una separación de funciones. Esto requiere que los administradores de bases de datos obtengan autorización previa del personal de seguridad para determinadas actividades.

Otras medidas de detección pueden proteger los miles de millones de SQL que provienen de la aplicación. El análisis de anomalías es una potente herramienta que puede inspeccionar cada SQL de la aplicación y alertar cuando se produce un cambio en el perfil de actividad de la aplicación.

Se pueden aplicar medidas similares a las conexiones locales o a cualquier otra cuenta.

Existen más capacidades para el análisis forense reactivo y proactivo. El primero tiene como objetivo investigar los eventos de seguridad, y el segundo proporciona visibilidad de la actividad para facilitar el diseño de controles, el análisis de deficiencias, la identificación de prácticas de seguridad deficientes y mucho más.

La conclusión es que controlar la actividad le permite proteger la base de datos contra todas las amenazas. Se necesita algo de tiempo y esfuerzo para determinar el mejor enfoque para cada subsección de la actividad, pero todo se puede proteger.

Reflexión Final

La seguridad de las bases de datos es imprescindible. Las bases de datos contienen los datos que debemos proteger, y salvaguardarlas es fundamental para la seguridad de la información. Los enfoques tradicionales son inadecuados y no logran proteger las bases de datos. Sin embargo, las soluciones modernas como Core Audit ofrecen una seguridad sólida y eficaz que reducirá significativamente el riesgo de una violación de datos.

Póngase en contacto con nosotros hoy mismo y déjenos ayudarle a proteger sus activos críticos.

Vivimos en una era de amenazas cibernéticas implacables. Los titulares hablan de ataques de ransomware, violaciones de datos y sofisticadas campañas de phishing. En respuesta, las organizaciones suelen apresurarse a reforzar sus defensas perimetrales, actualizar la seguridad de los puntos finales e implementar las últimas herramientas de supervisión de redes. Si bien estas medidas son sin duda importantes, se está gestando una crisis silenciosa en el corazón digital de muchas organizaciones: las bases de datos descuidadas.

Piénselo. ¿Dónde residen sus datos más críticos? La información de los clientes, los registros financieros, la propiedad intelectual, los datos sanitarios confidenciales… todo ello se canaliza a través de sus bases de datos. Esto las convierte en el objetivo definitivo de los actores maliciosos. Una violación a nivel de la base de datos puede tener consecuencias catastróficas, muy superiores al impacto de un punto final comprometido o una interrupción temporal de la red.

Sin embargo, ¿por qué la seguridad de las bases de datos suele quedar en un segundo plano? Hay varios factores que contribuyen a este peligroso descuido:

• La mentalidad de «ojos que no ven, corazón que no siente»: las bases de datos funcionan entre bastidores y, a menudo, son gestionadas por equipos especializados. Esto puede dar lugar a una falta de visibilidad y comprensión entre los responsables de seguridad en general con respecto a su verdadera vulnerabilidad.
• Visión estrecha impulsada por el cumplimiento normativo: aunque normativas como el RGPD, la HIPAA y la PCI DSS suelen abordar la protección de datos, su enfoque puede ser a veces más amplio, haciendo hincapié en los controles de acceso y la seguridad perimetral en lugar de en las medidas de seguridad granulares necesarias dentro de la propia base de datos.
• El factor «poco atractivo»: seamos realistas, la seguridad de las bases de datos no siempre acapara los titulares como un exploit de día cero o un ataque de un Estado-nación. Puede parecer compleja, técnica y menos impactante a primera vista que ver cómo un cortafuegos bloquea una conexión maliciosa.
• La ilusión del retorno de la inversión: calcular el retorno directo de la inversión en actualizaciones de seguridad de bases de datos puede resultar complicado. Es más fácil cuantificar el coste de un nuevo cortafuegos que el beneficio aparentemente intangible de prevenir una violación de datos.

Pero seamos sinceros: ¿puede su organización permitirse realmente no dar prioridad a la seguridad de las bases de datos?

Usted conoce las consecuencias de una violación de datos. Eso es lo que ocurre cuando alguien accede a su base de datos. Un coste que puede alcanzar millones de dólares en multas reglamentarias, honorarios legales, indemnizaciones a clientes, investigaciones forenses y mucho más. Además de los efectos duraderos del daño irreversible a la reputación cuando se pierde la confianza de los clientes y las partes interesadas.

Base de datos: tu prioridad desde el minuto cero

La realidad es que una seguridad sólida de las bases de datos no es solo otro elemento más de su lista de comprobación de seguridad, sino que es la base sobre la que se sustentan todas las demás medidas de seguridad. Es la prioridad cero. Sin ella, todos sus sofisticados cortafuegos y sistemas de detección de puntos finales pueden estar simplemente protegiendo una cámara acorazada vacía.

Piénselo de esta manera: no construiría una fortaleza con paredes endebles alrededor de una cámara del tesoro. Su base de datos es esa cámara del tesoro. Exige la protección más sólida y sofisticada que pueda permitirse.

Invertir en seguridad de bases de datos: una inversión a su futuro

El argumento de que la seguridad de las bases de datos es difícil de rentabilizar es erróneo. Piense en los posibles costes que se evitan al prevenir una filtración de datos. El ahorro en multas, litigios, pérdida de clientes y daños a la reputación supera con creces la inversión en seguridad de bases de datos.

Pero lo más importante es que pasarse a una solución moderna de seguridad de bases de datos le permitirá ahorrar dinero. Esto se debe a que las soluciones modernas pueden hacer más con menos:

• Menor impacto en la base de datos. Core Audit tiene un impacto insignificante en sus servidores de bases de datos, lo que le da más poder para gestionar su negocio.
• Menos hardware. Core Audit requiere menos recursos para funcionar. Ahorrará dinero en CPU, memoria y espacio en disco. Podrá hacer más con menos.
• Menos tiempo. Con informes y alertas más eficientes, análisis de anomalías y mucho más, dedicará menos tiempo a la seguridad de las bases de datos.
• Visibilidad completa. Con análisis forenses proactivos, obtendrá una visibilidad completa de todo lo que ha ocurrido en su base de datos. Sabrá lo que está pasando, por lo que podrá mejorar las prácticas de seguridad y diseñar controles adecuados.
• Mayor seguridad. Y lo más importante, obtendrá una mayor seguridad. Podrá defenderse de cualquier amenaza y garantizar que sus datos estén bien protegidos.

Todo esto se traduce en dinero. Dinero real en hardware y recursos humanos, por no hablar de evitar los costes de las catástrofes.

No persigas tendencias y protege lo que más importa

Es hora de ir más allá del atractivo de las soluciones de seguridad de moda y centrarse en la verdad fundamental: sus datos son su activo más valioso y su base de datos es su principal guardián. Una postura de seguridad de bases de datos sólida y bien mantenida no es solo una buena idea, es una necesidad empresarial.

En lugar de adoptar al azar la última moda en seguridad, dé un paso atrás y realice una evaluación exhaustiva del panorama de seguridad de su base de datos. ¿A qué amenazas se enfrenta y está preparado para hacerles frente? Invierta en soluciones que le proporcionen la protección que necesita.

No espere a que se produzca una violación de datos para convencerse. El coste de la inacción supera con creces la inversión en seguridad moderna para bases de datos. Haga de la seguridad de las bases de datos su prioridad número uno hoy mismo y garantice la seguridad y la resiliencia a largo plazo de su organización. Su futuro depende de ello.

El seguimiento de los cambios en los datos es una piedra angular del mantenimiento de registros y la integridad de los datos. En el mundo altamente regulado de la banca y las instituciones financieras, la capacidad de realizar un seguimiento preciso y reconstruir los cambios en los datos no es solo una buena práctica, sino un requisito normativo fundamental.

Las instituciones financieras manejan información de clientes y datos transaccionales en los que incluso una alteración menor y no documentada puede tener importantes implicaciones fiscales y legales. Este artículo explora el seguimiento de los cambios en los datos y examina su implementación práctica en las bases de datos Oracle y SQL Server.

¿Qué es el seguimiento de los cambios en los datos?

En lo que respecta a la auditoría, el mantenimiento de registros y la integridad de los datos, hay tres medidas que los clientes encuentran confusas:

• La auditoría de consultas tiene como objetivo registrar todas las solicitudes de acceso para ver los datos. Este tipo de auditoría tiene como objetivo combatir el robo de datos mediante la inspección y/o el control de quién accede a qué. Eso es algo en lo que podemos ayudarle, pero no entra dentro del alcance de este artículo.
• La auditoría de modificación de datos tiene como objetivo evitar cambios no autorizados mediante la inspección y/o el control de quién cambia los datos. Esto incluye insertar filas, eliminar datos o modificar registros. También podemos ayudarle con esto, pero no entra dentro del alcance de este artículo.
• El seguimiento de cambios en los datos tiene como objetivo rastrear el linaje de cada dato, lo que le permite deshacer los cambios. Ese es el tema de este artículo, y vamos a explicarlo un poco más.

Entonces, ¿en qué se diferencia el seguimiento de cambios en los datos de la auditoría de modificaciones?

Supongamos que tenemos una columna de saldo y alguien emite un SQL que lo cambia. Por ejemplo:

saldo = saldo + 1000

En la auditoría, registramos el SQL, quién lo ejecutó y cuándo. En el seguimiento de cambios en los datos, registramos los valores anteriores y nuevos del saldo (por ejemplo, 10 000 y 11 000). Esos valores no están en el SQL, ya que el SQL solo pidió añadir 1000 al valor anterior.

Si el SQL anterior modificó 10 filas, la auditoría registrará el SQL y el hecho de que modificó 10 filas. Sin embargo, la auditoría no enumerará qué filas cambiaron. El seguimiento de cambios en los datos registrará cada cambio, enumerando los 10 valores anteriores y los 10 nuevos.

Del mismo modo, si alguien eliminó varias filas, la auditoría registrará el SQL y el número de filas eliminadas. El seguimiento de cambios registrará los valores de cada fila eliminada.

El seguimiento de cambios en los datos es un requisito importante común en entornos altamente regulados, como bancos e instituciones financieras. Significa que conoceremos los valores antes y después de cada cambio. Esto es fundamental para llevar un registro detallado.

Las Regulaciones

El seguimiento de los cambios en los datos es la piedra angular de un buen mantenimiento de registros. Significa que conocemos el origen de cada dato y podemos revertirlo si alguien realiza un cambio no autorizado. Por lo tanto, es un requisito de todas las regulaciones de cumplimiento para bancos y otras instituciones financieras.

En los Estados Unidos, la FINRA (Autoridad Reguladora de la Industria Financiera) y el FFIEC (Consejo Federal de Examen de Instituciones Financieras) publican directrices para bancos e instituciones financieras.

Por ejemplo, la norma 4511 de la FINRA y la norma 17a-4 de la SEC en la que se basa tratan sobre el mantenimiento de registros electrónicos y exigen que el registro de auditoría incluya «todas las modificaciones y eliminaciones del registro o de cualquier parte del mismo» (17a-4(f)(2)(i)(A)(1)).

Existen directrices similares del BCE (Banco Central Europeo), la BaFin (Bundesanstalt für Finanzdienstleistungsaufsicht) en Alemania, la ACPR (Autorité de contrôle prudentiel et de résolution) en Francia y la CNMV (Comisión Nacional del Mercado de Valores) en España.

En América Latina, los reguladores también tienen requisitos estrictos de la CNBV (Comisión Nacional Bancaria y de Valores) en México, la SFC (Superintendencia Financiera de Colombia) en Colombia, la SBS (Superintendencia de Banca, Seguros y Administradoras Privadas de Fondos de Pensiones) en Perú y muchos más.

BCBS 239 (Comité de Supervisión Bancaria de Basilea – Principios para la agregación eficaz de datos de riesgo y la presentación de informes de riesgo) es una guía bancaria global que influye en la mayoría de los reguladores de todo el mundo. La mayoría de las interpretaciones tienden a coincidir en que también exige este tipo de registro detallado.

Implementaciones

El seguimiento de los cambios en la base de datos es posible a través de diferentes mecanismos. Aunque cada base de datos es ligeramente diferente y se revisa a continuación, los principios generales y las ventajas e inconvenientes son similares.

Los desencadenadores son fragmentos de código que se ejecutan cuando se producen cambios en los datos. Uno de los métodos más sencillos para realizar un seguimiento de los cambios en una base de datos es utilizar un desencadenador que registre los cambios en una tabla de auditoría. Esto es algo que cualquier administrador de bases de datos puede implementar en cualquier base de datos.

Sin embargo, los disparadores tienen un gran inconveniente: un alto impacto en el rendimiento. El registro adicional en la tabla de auditoría forma parte de la transacción y la ralentiza considerablemente. El impacto típico es de al menos un 100 %, lo que hace que todo tarde el doble de tiempo.

Los desencadenantes ligeros son una variante de la implementación clásica de los desencadenantes. En lugar de una inserción, ejecutan un SQL ficticio que incluye los datos que han cambiado. El uso de un SQL ficticio reduce significativamente la sobrecarga de rendimiento. Core Audit Full Capture puede ver estos SQL internos en los desencadenantes, extraer los datos y registrarlos en el servidor Core Audit.

Una de las ventajas de los desencadenantes ligeros es que permiten correlacionar los cambios en los datos con el resto de los datos de auditoría, incluida la sesión exacta en la que se produjeron.

Los desencadenantes ligeros funcionarán en cualquier base de datos siempre que se disponga de la tecnología Core Audit Full Capture para recopilar los datos. Por ejemplo, la información de los desencadenantes ligeros de SQL Server almacenada en Core Audit puede tener este aspecto:

Time	2025/05/16 15:38:19
Session	714000000000002308 (link to Core Audit session)
Username	sa
Session Info	OSQL-32 local
Owner	test
Table	emp
Operation	UPDATE
New Values	id=1 first=’John’ last=’Doe’ salary=11000
Old Values	id=1 first=’James’ last=’Doe’ salary=10000

Los registros de rehacer o registros de transacciones son nombres diferentes para lo mismo. Se trata de registros que existen en todas las bases de datos y que registran cada cambio en los datos. Son una parte fundamental de la base de datos, ya que permiten la recuperación tras un fallo y la recuperación en un momento determinado, lo que garantiza la integridad de los datos.

Dado que estos registros siempre existen y registran cada cambio, se pueden extraer para obtener los cambios que se desean rastrear. La principal ventaja de extraer estos registros es que no forma parte del SQL y no ralentiza las transacciones de la base de datos.

La desventaja es que la extracción de estos registros aumenta el consumo de recursos en el servidor y, lo que es más importante, se limita a la información almacenada en los registros. Por ejemplo, algunas bases de datos registran la información de la sesión, mientras que otras solo registran el cambio en sí, sin ninguna referencia a quién lo ha realizado. A continuación se ofrece información específica para cada tipo de base de datos, incluidas las desventajas que dependen de la base de datos.

Registros de rehacer de Oracle

Puede controlar la información de los registros de rehacer de Oracle a través de la configuración de registro suplementario de Oracle. Si su objetivo es extraer cambios de los registros, debe, como mínimo, ejecutar este SQL:

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

Sin ello, «update» a veces aparece como «delete» e «insert». Puede habilitar el registro adicional para registrar más información sobre claves primarias, otras columnas y mucho más.

Oracle Logminer le permite consultar los registros de rehacer en línea y archivados para extraer información de los registros de rehacer de Oracle.

Core Audit puede utilizar Logminer para consultar los registros de rehacer y almacenar la información en el servidor Core Audit. Por ejemplo, la información de Logminer almacenada en Core Audit puede tener este aspecto:

Time	2025/05/15 12:22:55
Session	68
Serial#	3787
Username	HRAPP
Session Info	login_username=HRAPP client_info= OS_username=bluecore Machine_name=WORKGROUP\BLUECORE2 OS_terminal=BLUECORE2 OS_process_id=5976:5220 OS_program_name=sqlplus.exe
Owner	HRAPP
Table	SALARIES
Operation	UPDATE
Redo SQL	update “HRAPP”.”SALARIES” set “SALARY” = ‘11000’ where “SALARY” = ‘10000’ and ROWID = ‘AABnEEAAEAAAAJUAAE’;
Undo SQL	update “HRAPP”.”SALARIES” set “SALARY” = ‘10000’ where “SALARY” = ‘11000’ and ROWID = ‘AABnEEAAEAAAAJUAAE’;
New Values	Salary=11000
Old Values	Salary=10000
Field

Registros de transacciones de SQL Server

Los registros de transacciones de SQL Server no contienen información de sesión, por lo que es imposible vincular los cambios a los usuarios que los realizaron.

Core Audit puede aprovechar el motor de replicación de SQL Server para extraer información de los registros de transacciones. Se trata de una extracción de alto rendimiento casi en tiempo real, pero ocupa el motor de replicación, por lo que no se puede utilizar la replicación de SQL Server junto con la extracción de registros de transacciones de Core Audit.

Por ejemplo, la información de los registros de transacciones de SQL Server almacenada en Core Audit puede tener este aspecto:

Time	2025/05/16 13:42:33
Owner	test
Table	emp
Operation	update
Redo SQL	update [dbo].[emp] set [salary] = 11000 where [id] = 1

SQL Server también cuenta con mecanismos integrados para extraer información de los registros de transacciones. Estos mecanismos también se limitan a la misma información disponible en los registros. El seguimiento de cambios es el mecanismo antiguo, y la captura de datos modificados (CDC) es el más reciente. CDC es mejor, pero aún así requiere cierta administración y mantenimiento regular, y los resultados no son fáciles de entender.

Resumen

El seguimiento de los cambios en los datos es vital para un buen mantenimiento de los registros y esencial en los sistemas bancarios y financieros.

Este requisito tiene múltiples opciones de implementación, y Core Audit las admite todas. Aunque la mejor opción puede depender de su entorno, muchos clientes consideran que las limitadas desventajas de los desencadenantes ligeros y la alta calidad de la información son convincentes.

Como profesionales de la seguridad, estamos programados para mirar hacia afuera. Las luces rojas intermitentes, los escaneos de puertos siniestros, los rumores de sofisticadas APT: estas son las narrativas que captan nuestra atención. Construimos fortalezas digitales, fosos de cortafuegos y torres de vigilancia de sistemas de detección de intrusiones, todo ello apuntando hacia un adversario externo sin rostro.

¿Y por qué no íbamos a hacerlo? A los medios de comunicación les encantan las buenas historias sobre hackers. Los titulares gritan sobre ataques de estados-nación y bandas de ransomware que secuestran empresas. Es un drama apasionante, lleno de destreza técnica y figuras oscuras.

Pero, ¿y si la verdadera amenaza no acecha en la oscuridad exterior, sino que se encuentra cómodamente dentro de tus propias paredes? ¿Y si las llaves de tu reino ya están en manos de alguien en quien confías, o crees confiar?

Dejemos de lado las estadísticas abstractas por un momento y pintemos un cuadro.

Imagina a Jennifer, una administradora de bases de datos que lleva cinco años en la empresa. Conoce los sistemas al dedillo, tiene acceso privilegiado a tus datos más sensibles y, en general, se la considera una empleada fiable. Pero Jenny está ahogada en deudas personales y una figura oscura en Internet le ha ofrecido mucho dinero a cambio de una copia de los registros de los clientes. Es algo puntual, se dice a sí misma. Nadie lo sabrá nunca.

O pensemos en Mark, un gerente de ventas descontento que se siente ignorado para un ascenso. Todavía tiene acceso a datos críticos de ventas y decide sabotear sutilmente los registros, sesgando los informes y socavando a sus antiguos superiores. Es su forma de vengarse, un acto silencioso de venganza digital.

Luego está David, un becario bienintencionado pero despistado, que trabaja desde casa y deja su ordenador desatendido. Un amigo malintencionado de su compañero de piso se aprovecha del acceso interno legítimo de David. Navega con facilidad por su red supuestamente segura y accede directamente a sus bases de datos.

No se trata de villanos de Hollywood con sudaderas con capucha. Son personas normales que se enfrentan a presiones cotidianas y que, de forma intencionada o no, pueden convertirse en conductos o en la fuente directa de devastadoras violaciones de datos.

Piénsalo:

• Tienen las llaves: los empleados internos poseen credenciales y permisos legítimos que los atacantes externos solo pueden soñar con obtener. Ni siquiera necesitan eludir tus defensas perimetrales cuidadosamente construidas.
• Conocen el terreno: están familiarizados con tus protocolos de seguridad, comprenden las estructuras de tus bases de datos, pueden localizar dónde se encuentran los datos y saben cómo modificarlos. Utilizan estos datos a diario y los conocen al dedillo. Por eso los ataques internos son mucho más peligrosos y difíciles de detectar.
• El daño puede ser catastrófico: un empleado malintencionado con el acceso adecuado puede extraer grandes cantidades de datos y modificar información crítica sin que nadie se dé cuenta. Pueden causar un daño irreparable a la reputación y a los resultados de su organización.

Dedicamos mucho tiempo y energía a construir muros, pero ¿qué pasa con las puertas y ventanas que dejamos abiertas a sabiendas para los que están dentro? Supervisamos meticulosamente el tráfico de red en busca de anomalías, pero ¿aplicamos el mismo nivel de escrutinio a la actividad interna?

La cifra del 20 % no es solo una estadística; representa empresas reales, personas reales y consecuencias reales. Aparece cada año en el DBIR (Informe de investigación sobre violaciones de datos) de Verizon, y es una parte significativa del panorama de las violaciones que no podemos permitirnos ignorar.

La seguridad centrada en los datos no es solo una «mejor» defensa contra las amenazas externas; es la única defensa verdadera contra el enemigo interno. Al centrarse en proteger los datos en sí, se deja sin poder al atacante, ya sea externo o interno, incluso si logra penetrar en su perímetro o aprovechar credenciales legítimas.

Recuerde que el hombre del saco en el borde de la red no suele ser un hacker experto, sino un script kiddy que busca una vulnerabilidad oportunista. El verdadero hombre del saco es el que toca sus datos todos los días y puede causar un daño inimaginable con solo pulsar unas teclas.

Tenga en cuenta estas prácticas recomendadas de seguridad de bases de datos.

Imagine que Jennifer intenta extraer registros de clientes, pero es detectada por una alerta de anomalía de Core Audit o se le deniega el acceso por una política de bloqueo SQL de Core Audit. Imagine que los intentos de Mark de sabotear los datos se marcan inmediatamente como un cambio en su perfil de actividad. Imagine que el amigo que utiliza el ordenador de David no consigue extraer los datos porque está accediendo a una cantidad inusual de información confidencial.

No se trata de desconfiar de todos los miembros de su organización. Se trata de reconocer que la naturaleza humana es compleja, que las circunstancias cambian y que incluso las personas bienintencionadas pueden ser explotadas. Se trata de implementar una estrategia de seguridad que asuma que se producirá un ataque a la base de datos, independientemente de su origen.

Así que, la próxima vez que revise su postura de seguridad, tómese un momento para mirar hacia dentro. Más allá de las deslumbrantes luces del panorama de amenazas externas, existe una realidad más silenciosa, quizás menos dramática, pero igualmente peligrosa dentro de sus propias paredes digitales. No permita que el enfoque en el exterior le impida ver las vulnerabilidades internas. Sus datos, y el futuro de su organización, dependen de ello. Es hora de sentir el peso de la amenaza interna, no solo de reconocer su existencia.

¿Por qué es tan importante la seguridad de las bases de datos?

Una brecha de datos grave significa que alguien ha accedido a su base de datos y ha robado datos. Las bases de datos son las guardianas de sus datos, y cualquiera que quiera obtenerlos debe hacerlo a través de la base de datos.

Aunque debe proteger todos los componentes de la infraestructura, ninguno es más importante que la base de datos. Independientemente de cómo se inicien, todas las brechas terminan en la base de datos.

Muchas organizaciones no prestan suficiente atención a la seguridad de las bases de datos por diversas razones. Algunas no creen que sea posible protegerlas, otras piensan que no disponen de los recursos necesarios, les preocupan los costes, etc. Pero la verdad es que la tecnología adecuada y los conocimientos técnicos de los socios le permitirán proteger sus bases de datos a un precio asequible. Y esa protección es el paso más importante en la seguridad informática.

Amenazas a las bases de datos

Por extraño que parezca, Internet está lleno de tonterías sobre las amenazas a las bases de datos. Incluso blogs y artículos de fuentes acreditadas repiten estas afirmaciones sin fundamento. La siguiente lista pretende aclarar estos hechos:

Amenazas Internas

Sí, la amenaza interna es un gran problema. Para cuantificarla con mayor precisión, alrededor del 20 % de las brechas de datos involucran a un actor interno malintencionado. El informe DBIR de Verizon es una buena fuente de información, ya que cada año presenta cifras similares. Algunos países, como Alemania, informan que la amenaza interna alcanza hasta un 26 %. Independientemente de si se trata de 1 de cada 4 o 1 de cada 5 brechas, se trata de una amenaza significativa que no debemos ignorar.

Esta amenaza es otra razón más por la que las organizaciones deben invertir en la seguridad de las bases de datos. Las defensas centradas en los datos, en general, y la seguridad de las bases de datos, en particular, son las únicas defensas contra los actores internos.

Amenazas externas

La mayoría de los ataques provienen de agentes externos. Sin embargo, es fundamental comprender cómo estos agentes penetran en la base de datos. Dado que las bases de datos no deben estar conectadas directamente a Internet, todos estos ataques deben realizarse a través de un intermediario.

Desde el punto de vista de la seguridad de las bases de datos, es irrelevante si el atacante ha entrado en la organización mediante un ataque de phishing, algún otro tipo de ataque de ingeniería social, un error de configuración o cualquier otra cosa. Lo importante es que ha entrado y ahora va a por tus datos. El resto de esta lista desglosa cómo ocurre esto.

Acceso al servidor local

Aunque es difícil cuantificar la amenaza que supone el acceso al servidor de la base de datos local, es posible establecer un límite mínimo. Ten en cuenta que más del 40 % de las brechas de datos implican ransomware y que, por definición, casi todos los ataques de ransomware deben comprometer el servidor de la base de datos. Simplemente no hay otra forma de cifrar los archivos de datos.

Por lo tanto, independientemente de si la amenaza del acceso al servidor local es del 40 % o superior, se trata de una amenaza significativa que no podemos ignorar.

Cuentas válidas

Las amenazas a través de cuentas válidas incluyen el robo de credenciales, la suplantación de identidad y ataques similares. Pero todo lo demás en esta lista de amenazas, como las amenazas internas, las inyecciones SQL y otras, también se manifiesta a través de una cuenta válida. Aunque no podemos estimar el nivel exacto de amenaza de las cuentas válidas, estas son el método principal para penetrar en una base de datos.

Pero, ¿por qué agrupar el robo de credenciales con, por ejemplo, el abuso de privilegios por parte de actores internos? Se debe a la forma en que abordamos estas amenazas. Si no podemos confiar en la actividad de las conexiones autenticadas, debemos identificar la actividad maliciosa dentro de esas conexiones. No importa si alguien robó las credenciales o si el usuario abusó de sus privilegios. Más adelante se profundizará en este tema.

Inyección SQL

Puede resultar sorprendente, pero no hay cifras fiables sobre el nivel de amenaza de la inyección SQL. Aunque se estima que es alto, especialmente para las aplicaciones conectadas a Internet, diferentes fuentes publican cifras muy dispares.

Aunque la inyección SQL es solo un tipo de vulnerabilidad de las aplicaciones, es sin duda la más común. Las soluciones de seguridad para aplicaciones web, como WAF, no logran abordarla de manera consistente, mientras que las soluciones modernas de seguridad de bases de datos, como Core Audit, ofrecen una defensa eficaz. Las defensas modernas de bases de datos abordan más que la inyección SQL y, hoy en día, son la solución preferida. La situación actual contrasta fuertemente con la de hace dos décadas, cuando surgió la tecnología WAF.

Errores humanos

Los errores humanos pueden crear vulnerabilidades en las bases de datos. Por ejemplo, al otorgar demasiados privilegios, descuidar el cierre de cuentas, utilizar contraseñas sencillas, etc. Sin embargo, las pruebas sugieren que esto no es una causa significativa de brechas de la seguridad de las bases de datos. Si bien los errores humanos son una razón fundamental para la penetración del perímetro, no son una causa para la penetración de las bases de datos.

No obstante, identificar y corregir dichos errores es una buena práctica. Establecer procesos de control de cambios (véase más abajo) es un paso esencial en esa dirección.

Riesgos menores

Algunas amenazas teóricas suponen amenazas minúsculas para las bases de datos. Las mencionamos porque existen afirmaciones de este tipo en diversos blogs y artículos. Sin embargo, son absurdas.

Las bases de datos modernas no tienen vulnerabilidades significativas, desbordamientos de búfer ni debilidades similares. Al menos, no las que son responsables de una brecha, ya que esta falta de vulnerabilidades es particularmente cierta en el caso de las vulnerabilidades relacionadas con la autenticación que permiten a los atacantes conectarse sin contraseña. No existe ningún paquete mágico ni puerta trasera secreta no documentada que permita a alguien acceder a su base de datos. Si bien es esencial aplicar parches de seguridad, es raro que se aproveche una vulnerabilidad de la base de datos sin un nombre de usuario y una contraseña válidos.

Además, no se debe conectar una base de datos directamente a Internet. Las bases de datos deben residir únicamente en redes internas seguras. Por lo tanto, las bases de datos no son vulnerables a los ataques de denegación de servicio (DoS). Y eso se aplica doblemente a los ataques de denegación de servicio distribuido (DDoS). Cualquier intento de proteger una base de datos contra tales ataques es inútil.

Resumen de amenazas

En resumen, una brecha de la base de datos aprovecha un usuario y una contraseña válidos para conectarse a la base de datos. Estas son las vías principales:

• Amenaza interna del administrador de bases de datos (DBA). Se trata de un abuso de privilegios por parte de un administrador de bases de datos.
• Compromiso de la cuenta del DBA. Se trata de un agente externo que ha penetrado el escritorio del DBA, ha robado la contraseña del DBA o la contraseña de una cuenta con privilegios compartidos (como SYS o SA).
• Acceso local. La mayoría de las bases de datos permiten conexiones no autenticadas desde cuentas específicas del sistema operativo en el servidor de la base de datos. Una brecha de este tipo suele ser obra de un agente externo, pero también puede ser un abuso de privilegios.
• Compromiso de la cuenta de la aplicación. Se trata de un agente externo que ha obtenido acceso a la contraseña de la aplicación, o de un agente interno que abusa de su acceso.
• Compromiso de la aplicación. Se trata de un exploit de una vulnerabilidad de la aplicación, como una inyección SQL.
• Otro abuso o compromiso de cuentas. Al igual que la cuenta DBA, otras cuentas de la base de datos pueden ser objeto de abuso por parte de sus legítimos propietarios o comprometidas por un agente externo.

Prácticas básicas

Las prácticas básicas de seguridad tienen como objetivo reforzar una base de datos, pero no abordan las amenazas comunes. Se trata de pasos esenciales, pero no impedirán una brecha de la seguridad.

1. Cifrado. Active el cifrado de red y de disco. Aunque ninguna amenaza común se dirige a los paquetes de red o a los archivos, es una buena práctica y fácil de implementar.
2. Seguridad de las cuentas:

• Inventario de cuentas. Haga una lista de todas las cuentas de la base de datos e identifique a las personas o aplicaciones asociadas a ellas.
• Cuentas inactivas. Cierre las cuentas inactivas.
• Cuentas individuales. Asegúrese de que todas las cuentas sean cuentas individuales, excepto las cuentas de aplicaciones y las cuentas de administración compartidas integradas (como SYS o SA).
• Contraseña. Asegúrese de que ninguna contraseña sea la contraseña predeterminada o una contraseña codificada.
• Política de contraseñas. Active las políticas de contraseñas que requieran una longitud mínima de contraseña, complejidad de contraseña, bloqueo de cuentas, etc.
• Privilegios mínimos. Asegúrese de que todas las cuentas tengan los privilegios mínimos que las personas necesitan para realizar sus tareas.

3. Parches. Instale todos los parches de seguridad para la base de datos y todo el software y las herramientas asociados. Esto incluye el software de aplicación, las herramientas de generación de informes, las herramientas de administración de bases de datos, las herramientas de gestión del rendimiento, etc.

4. Control de cambios. Implemente un proceso de control de cambios y valide de forma independiente que todos los cambios estén aprobados. Esto incluye cambios en la configuración, los usuarios, los permisos, los objetos de la base de datos, etc.

Buenas prácticas

Como se mencionó anteriormente, las medidas de seguridad básicas son esenciales, pero no pueden hacer frente a las principales amenazas. Para hacer frente a estas amenazas se utiliza el control de actividad, el método principal para la seguridad de las bases de datos.

Casi todas las amenazas provienen de conexiones válidas que utilizan privilegios adecuados. Por lo tanto, la única forma de hacerles frente es inspeccionando cada SQL en cada conexión y aplicando los controles detectivos o preventivos adecuados.

Dado que los controles de actividad tienen como objetivo garantizar que las conexiones solo realicen actividades «buenas», independientemente de si la amenaza es interna o externa, lo que importa es el perfil de actividad de la cuenta y cómo evitar que realice acciones maliciosas.

1. Cuentas DBA y conexiones locales. Por lo general, los administradores de bases de datos (DBA) no deben acceder a datos confidenciales. Muchas veces, tampoco ejecutan DML. Eso significa que alertar o bloquear estas actividades en las cuentas administrativas es una forma excelente de prevenir una brecha. Los controles internos de la base de datos no pueden hacer eso, pero el control avanzado de actividades sí. Estos controles mitigan cualquier amenaza que se manifieste a través de una cuenta privilegiada, incluido el abuso por parte de un DBA, el robo de credenciales y las conexiones locales.
2. Cuenta de aplicación. Las aplicaciones tienden a repetir las mismas construcciones SQL una y otra vez. Aunque puede haber varios cientos de miles de construcciones, en última instancia, todas se repiten. Un análisis de anomalías de la actividad de la aplicación es una forma excelente de identificar cambios en el perfil de actividad de la aplicación. Esto funciona para detectar inyecciones SQL, así como la mayoría de los tipos de comportamiento indebido de las aplicaciones.
   Aunque esto también detecta el abuso de la cuenta de la aplicación o el robo de credenciales, también se pueden detectar mediante controles de sesión (que se describen a continuación).
3. Actividad DDL. Ciertos tipos de actividad, como DDL y DCL, merecen precauciones adicionales. Los DDL permiten administrar la base de datos, y los DCL son un subtipo relacionado con la autorización (usuarios y concesiones). La práctica habitual es informar sobre estos SQL para garantizar que los cambios sean aprobados.
4. Tablas confidenciales. Controlar el acceso a los datos confidenciales es fundamental, y el análisis de anomalías es una medida eficaz para identificar cambios en el comportamiento relacionado con estas tablas. Esto permitirá detectar accesos inusuales por parte de los administradores de bases de datos u otras cuentas, cambios peligrosos en el comportamiento de la aplicación y mucho más.
5. Programas sensibles. Algunos programas no tienen restricciones integradas sobre lo que pueden hacer sus usuarios y les permiten ejecutar cualquier SQL. Los administradores suelen utilizar estos programas para gestionar la base de datos, y los analistas a veces escriben SQL para aprovechar al máximo las capacidades de la base de datos. La ausencia de restricciones merece una supervisión adicional que depende de cómo utilicen estas personas los programas. Puede implicar la supervisión del acceso a tablas sensibles, DML, anomalías, etc.
6. Sesiones y origen de la actividad. El control de sesiones es el tipo de control más sencillo y fácil de entender. Implica supervisar quién se conecta, desde dónde y cuándo. Los informes pueden referirse a un subconjunto de cuentas, como los administradores de bases de datos o la aplicación, para garantizar que todas las conexiones proceden de las fuentes esperadas. Las anomalías son alertas cruciales que destacan un cambio en el origen de la actividad (por ejemplo, una IP diferente), una hora inusual del día, un mayor volumen de actividad y mucho más.

Ponte a Prueba

Las siguientes preguntas evalúan su nivel de control sobre sus bases de datos. Si no está seguro, considere algunas de las mejores prácticas recomendadas anteriormente.

1. ¿Recibe alertas falsas positivas de su solución de seguridad de bases de datos?
   Ningún sistema de seguridad es perfecto. Todas las soluciones equilibran los falsos positivos y los falsos negativos (eventos de seguridad no detectados). No recibir falsos positivos significa que su seguridad es demasiado laxa o inexistente. Significa que no recibirá ninguna alerta aunque se produzca una brecha de seguridad.
2. ¿Sabe quién ha accedido a sus datos confidenciales durante la última semana?
   Saber quién accede a los datos confidenciales de su base de datos es un indicador clave de concienciación. Si no sabe la respuesta, es poco probable que sepa cuándo se produce un acceso malicioso. También es poco probable que pueda llevar a cabo una investigación forense satisfactoria de una brecha de seguridad.
3. ¿Sabe qué usuarios, programas e IP han accedido a su base de datos durante la última semana?
   Esa es una pregunta fundamental sobre el control de sesiones. Conocer las fuentes de actividad de su base de datos es un control esencial. Si no lo sabe, no sabrá si se ha producido un robo de credenciales y no podrá llevar a cabo una investigación forense.
4. ¿Cree que sabría si un intruso ha aprovechado el acceso local o una cuenta de DBA?
   Esa es una pregunta más compleja, ya que un intruso podría utilizar la misma fuente de actividad que el usuario real. Sin embargo, es una prueba crítica, ya que se trata de vectores de ataque muy populares.
5. ¿Cree que sabría si se ha producido un intento de inyección SQL?
   La inyección SQL se considera una amenaza importante y el principal vector de ataque a las aplicaciones. También es muy difícil de detectar, y el análisis de anomalías es el único método eficaz.

Una postura de seguridad adecuada debería permitirle responder a estas preguntas. Al fin y al cabo, cubren las vías más populares para la brecha de datos.

Reflexiones Finales

La seguridad de las bases de datos es fundamental para proteger tus datos. En este artículo se explican las principales amenazas, cómo abordarlas y cómo ponerse a prueba. Si no controla sus bases de datos, es mucho más probable que sufra una brecha de datos y es poco probable que se entere.

Toma el control de tus bases de datos. ¡Ponte en contacto con nosotros hoy mismo!

Nosotros, como profesionales de la seguridad, operamos en un reino de lógica, evaluación de riesgos y defensa proactiva. Predicamos el modelo de seguridad por capas, el principio del mínimo privilegio y la importancia de la defensa en profundidad. Sin embargo, hay un trasfondo persistente, casi desconcertante, en nuestro campo: la creencia de que la seguridad a nivel de aplicación es el bastión definitivo, un escudo suficiente para salvaguardar nuestro bien más preciado: los datos que residen en la base de datos.

Seamos claros: esta creencia es una falacia peligrosa. Aunque la seguridad de las aplicaciones es innegablemente crucial, considerarla una estrategia completa de protección de datos es como fortificar la puerta principal de una casa dejando las ventanas traseras abiertas de par en par. Comprendemos las vulnerabilidades inherentes a las aplicaciones: el flujo interminable de errores, las complejidades de las diversas arquitecturas, la pura imposibilidad de lograr un código perfecto. Lo sabemos. Sin embargo, el enfoque, el presupuesto y la atención a menudo se inclinan desproporcionadamente hacia la seguridad de la capa de aplicación, dejando expuesto el corazón mismo de nuestros datos.

¿A qué se debe esta irracionalidad? Tal vez sea la complejidad percibida de la seguridad de las bases de datos, la sensación de que se trata de una caja negra. Tal vez sea el atractivo de las correcciones inmediatas a nivel de aplicación, la sensación tangible de parchear una vulnerabilidad conocida. Pero sea cual sea la razón, esta disonancia cognitiva debe terminar. Tenemos que ir más allá de la comprensión intelectual y cultivar una creencia profunda e inquebrantable en la necesidad absoluta de contar con defensas sólidas para las bases de datos.

Considere los vectores de ataque que hacen que la seguridad centrada en las aplicaciones sea incompleta:

• La amenaza interna: La seguridad de las aplicaciones, por muy estricta que sea, ofrece poca protección contra un administrador de bases de datos malintencionado o comprometido. Estos individuos poseen las llaves del reino, eludiendo por completo los controles de las aplicaciones.

• Robo de credenciales: Los atacantes son cada vez más expertos en obtener credenciales legítimas, ya sea mediante phishing, ingeniería social o malware. Armados con las credenciales de la base de datos, pueden acceder directamente a los datos confidenciales y filtrarlos, haciendo que las medidas de seguridad de la aplicación sean irrelevantes.

• Exploits del sistema operativo: Una brecha en el nivel del sistema operativo del servidor puede otorgar a los atacantes acceso directo a la base de datos, eludiendo todas las salvaguardas de la aplicación.

• La inevitable brecha en las aplicaciones: Admitámoslo, a pesar de nuestros mejores esfuerzos, las aplicaciones tendrán vulnerabilidades. La inyección SQL, a pesar de ser una amenaza bien conocida, persiste. Y aunque las defensas a nivel de aplicación son vitales, la propia base de datos puede y debe actuar como última línea de defensa, detectando y evitando las consultas maliciosas antes de que causen daños.

Además, demos la vuelta al guión. En lugar de considerar la seguridad de la base de datos como una tarea separada y desalentadora, considere su poder para mejorar la seguridad de las aplicaciones. Unos controles sólidos de la base de datos, como la identificación de actividades anómalas de la aplicación a nivel de base de datos, pueden neutralizar eficazmente clases enteras de ataques a nivel de aplicación, como la inyección SQL. La base de datos se convierte en un participante activo en la postura de seguridad, no sólo en un repositorio pasivo.

Y aquí hay una verdad que debería resonar en nuestras mentes pragmáticas: la seguridad moderna de las bases de datos es a menudo más manejable y eficiente que asegurar el extenso panorama de las aplicaciones. Las API de bases de datos están bien definidas. Los métodos de acceso son claros y auditables. Las medidas de seguridad, desde el cifrado de datos en reposo y en tránsito hasta la auditoría robusta, el análisis de anomalías y el bloqueo avanzado de SQL, están fácilmente disponibles. Compárese esto con la caótica diversidad de arquitecturas de aplicaciones, lenguajes, marcos de trabajo y la constante aparición de nuevas vulnerabilidades. Proteger la base de datos proporciona un retorno de la inversión más centrado e impactante. Hable con nosotros y le mostraremos cómo.

Las estadísticas dibujan un panorama desolador. La mayoría de las violaciones de datos importantes se originan en el acceso directo a las bases de datos. Lo sabemos. Vemos los titulares. Comprendemos las implicaciones: ruina financiera, daños a la reputación, sanciones reglamentarias. Sin embargo, persiste la tendencia arraigada hacia la seguridad de las aplicaciones.

Las estadísticas dibujan un panorama desolador. La mayoría de las violaciones de datos importantes tienen su origen en el acceso directo a bases de datos. Lo sabemos. Vemos los titulares. Comprendemos las implicaciones: ruina financiera, daños a la reputación, sanciones reglamentarias. Sin embargo, persiste la tendencia arraigada hacia la seguridad de las aplicaciones.

Es hora de cambiar de mentalidad. La seguridad de las bases de datos no es un elemento más de la lista de comprobación, sino el cimiento de la protección de datos. Es el guardián silencioso que se mantiene firme incluso cuando se violan los muros de la aplicación. Es la capa crítica que puede transformar una catástrofe potencial en un incidente contenido.

No estamos tratando con usuarios finales ingenuos. Somos profesionales de la seguridad. Entendemos los principios. La desconexión no radica en el conocimiento, sino en la creencia, en interiorizar realmente la profunda importancia de la seguridad de las bases de datos.

Vayamos más allá de la reconfortante ilusión de la seguridad centrada en las aplicaciones. Defendamos la causa de una sólida protección de las bases de datos con el mismo fervor y dedicación que aplicamos a otros ámbitos críticos de la seguridad. Asignemos recursos, apliquemos las mejores prácticas y fomentemos una cultura en la que la seguridad de las bases de datos no sea una ocurrencia tardía, sino un pilar fundamental de nuestra estrategia de seguridad.

Los datos que se nos ha confiado proteger lo exigen. Lo exige nuestra integridad profesional. El panorama de la seguridad lo exige. Es hora no sólo de entender la lógica, sino de creer de verdad en el poder y la necesidad de proteger nuestras bases de datos. Las consecuencias de no hacerlo son demasiado graves como para ignorarlas.