¿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!