Cómo evaluar el riesgo de seguridad de sus bases de datos

Los datos se han convertido en uno de nuestros activos más importantes. Por lo general, almacenamos datos en bases de datos, por lo que saber cómo protegerlos es de vital importancia.

Este artículo puede ayudarlo a cuantificar el nivel de seguridad de sus bases de datos en una escala del 1 al 10. Los CISO y los administradores de bases de datos (DBA) pueden usarlo para determinar su nivel de madurez de seguridad e identificar pasos para mejorarlo aún más.

Encuentre la calificación de seguridad de su base de datos

La siguiente tabla resume las calificaciones de seguridad en una escala del 1 al 10, siendo uno el nivel de seguridad más bajo y diez el más alto. Todas las calificaciones son acumulativas, por lo que cada calificación incluye todos los requisitos para todas las calificaciones anteriores.

El orden de los niveles refleja tanto un aumento en la seguridad como un aumento en el costo y la complejidad. Los niveles más bajos se pueden lograr sin software adicional, pero lograr niveles más altos se vuelve cada vez más difícil y requiere productos adecuados.

Sin seguridad

La clasificación 1 es para bases de datos que no están protegidas. Todas las bases de datos proporcionan un nivel de seguridad inherente, incluso si no hizo ningún esfuerzo por protegerlas. Por ejemplo, requieren credenciales para conectarse y tener roles y privilegios. La gestión de datos en una base de datos es el primer paso para protegerla.

Seguridad estándar y menos privilegiados

La clasificación 2 es para bases de datos en las que tanto la base de datos como el sistema operativo se configuran siguiendo los estándares y las mejores prácticas de la industria.

Esta clasificación también requiere que todas las cuentas de la base de datos tengan menos privilegios, lo que significa que los privilegios otorgados a las cuentas son los mínimos necesarios para realizar sus funciones.

Como parte del requisito de la calificación 2, debe hacerse un esfuerzo por eliminar las cuentas compartidas. Si existen cuentas compartidas, no deberían estar en uso regular y sus credenciales deben mantenerse en secreto.

Limitar el uso es especialmente cierto para las cuentas compartidas privilegiadas integradas en la base de datos. Las cuentas de bases de datos como SYS y SYSTEM en Oracle o SA en SQL-Server no deben usarse con regularidad, y sus contraseñas deben mantenerse de forma segura con acceso limitado.

Este requisito puede ser un desafío cuando, por ejemplo, la aplicación utiliza una cuenta privilegiada o cuando las cuentas compartidas son parte de nuestra forma de operar. Sin embargo, reducir y controlar el uso de estas cuentas es esencial para la seguridad.

Cambie las instantáneas de control y metadatos

La clasificación 3 es para bases de datos que están bajo control de cambios. Eso significa que cualquier cambio en los metadatos, como usuarios, privilegios, configuración y objetos, debe pasar por un proceso de aprobación de control de cambios.

Como parte del requisito de la Clasificación 3, se debe realizar una instantánea diaria de la configuración, los usuarios, los privilegios y los metadatos del objeto. Los cambios entre instantáneas deben investigarse y aprobarse de inmediato.

También es aconsejable que estas instantáneas se comparen de forma cruzada con bases de datos similares para garantizar configuraciones, usuarios, privilegios, etc. consistentes y uniformes.

El desafío del control de cambios es que puede resultar engorroso y verse como una burocracia inútil. Sin embargo, la falta de control sobre los cambios de metadatos se convierte rápidamente en una falta de control sobre los datos.

Supervisión y revisión de sesiones

La calificación 4 es para bases de datos donde todos los inicios de sesión se monitorean y revisan regularmente. Los inicios de sesión de usuarios, programas o máquinas inesperados deben investigarse de inmediato.

Una de las formas más fáciles de violar la seguridad de la base de datos es mediante el robo de credenciales. Por ejemplo, robar un nombre de usuario y una contraseña de DBA otorgaría a un atacante acceso ilimitado a los datos. Monitorear los inicios de sesión permite mitigar este riesgo.

La mayoría de las bases de datos permiten auditar los inicios de sesión y los inicios de sesión fallidos con una sobrecarga mínima. El desafío de la implementación es proporcionar una revisión eficiente de la información a través de informes.

Auditoría SQL básica (DDL y DML)

La calificación 5 es para bases de datos donde la actividad de SQL de alto riesgo se registra, informa y revisa regularmente.

La actividad de SQL de alto riesgo incluye:

  • Todos los DDL (incluidos los DCL): SQL que modifican la configuración de la base de datos, los objetos, los usuarios, los privilegios, etc.
  • DML de fuentes inesperadas, como usuarios privilegiados y programas particulares
  • El objetivo de este requisito es aplicar el control a la actividad poco frecuente y de alto riesgo. La auditoría de actividades raras no suele generar una sobrecarga de rendimiento y requiere una inversión mínima de tiempo. El desafío de la implementación es permitir una revisión rápida y eficiente de las actividades.

Auditoría SQL completa y cifrado de red

La calificación 6 es para bases de datos bajo auditoría SQL completa donde toda la actividad SQL potencialmente riesgosa se registra, informa y revisa regularmente.

Eso se traduce en auditar una gran cantidad de actividad, incluidas las consultas. Por ejemplo:

  • Acceso a tablas sensibles con consultas y DML
  • Toda la actividad de DBA y usuarios privilegiados
  • Toda la actividad de programas de alto riesgo como SQL Plus, Management Studio, etc.
  • Actividad de la cuenta de la aplicación que no es de los servidores de la aplicación
  • Actividad sensible incluso cuando se realiza dentro de la base de datos mediante procedimientos almacenados o desencadenantes

La clasificación 6 también requiere que toda la actividad de la red de la base de datos esté completamente encriptada para evitar el rastreo y la suplantación de la red.

El objetivo de este requisito es comenzar a aplicar estrictas medidas de seguridad sobre la actividad SQL y prevenir muchos ataques a la red.

El cifrado de la actividad de la red viene integrado de forma gratuita en la mayoría de las bases de datos y es fácil de activar. El principal desafío de implementación en este requisito es que auditar demasiadas actividades sin una solución adecuada puede tener un impacto significativo en el rendimiento de la base de datos. Un desafío secundario es lograr informes eficientes para una revisión rápida de la información con una mínima inversión de tiempo.

Cuando busque una solución de auditoría, tenga en cuenta que algunos productos no evitan la sobrecarga de rendimiento de la base de datos, mientras que otros no admiten el cifrado de red.

Detección y alerta de anomalías de sesión

La calificación 7 es para bases de datos con detección automatizada y alertas sobre fuentes de actividad anómala. A diferencia de la revisión de sesión manual realizada en la Clasificación 4, esta clasificación requiere una automatización capaz de detectar y alertar sobre cambios en los perfiles de fuente de actividad.

Eso incluye:

  • Alerta sobre nuevos usuarios, programas, máquinas o una combinación de aquellos que se conectan a la base de datos
  • Detección de cuentas compartidas (cuentas utilizadas por varias personas), así como de personas que utilizan varias cuentas
  • El propósito de este requisito es complementar la revisión humana con la automatización que notará y destacará la actividad anómala. Eso ayuda a evitar la supervisión accidental, así como a garantizar una detección y una respuesta rápidas. La implementación requiere una solución adecuada para realizar el análisis.

Detección y alerta de anomalías SQL

La calificación 8 es para bases de datos con detección automatizada y alertas sobre actividad SQL anómala. A diferencia de las revisiones de SQL manuales en las calificaciones 5 y 6, esta calificación requiere una automatización capaz de analizar toda la actividad de SQL en la base de datos, incluida la actividad de la aplicación.

Eso incluye:

  • Comportamiento inusual de la aplicación, como posibles inyecciones de SQL
  • Niveles de actividad anormales. Por ejemplo, una cantidad inusualmente alta de SQL ejecutados o filas accedidas
  • Actividades en un momento extraño del día
  • Nuevos SQL que tocan tablas sensibles

El objetivo de este requisito va mucho más allá de evitar la supervisión accidental y mejorar el tiempo de detección. El objetivo es controlar el volumen de actividad imposiblemente alto en las bases de datos que no pueden someterse a revisión humana.

Incluso las bases de datos de baja actividad pueden ejecutar millones de consultas SQL por día y, sin automatización, es imposible aplicarles ningún nivel de control. La implementación requiere un software que pueda capturar toda la actividad con poca sobrecarga y realizar el análisis.

Revisiones forenses proactivas

La calificación 9 es para bases de datos con revisiones periódicas de actividades proactivas. Eso significa que una persona familiarizada con el perfil de actividad de las bases de datos inspecciona regularmente la actividad (por ejemplo, una vez al mes).

El propósito de la revisión es identificar comportamientos que de otro modo podrían pasar desapercibidos, incluidos tanto el abuso interno como los ataques externos. La inspección también podría resaltar lagunas en los controles, prácticas de riesgo y más.

La implementación requiere una solución que pueda capturar toda la actividad con una sobrecarga mínima, reducirla y almacenarla en una cantidad razonable de espacio en disco y proporcionar las herramientas forenses para analizarla y revisarla.

Restringir el acceso a los administradores de bases de datos y las aplicaciones.

La clasificación 10 es para bases de datos que restringen el acceso a cuentas con acceso ilimitado a los datos, por ejemplo, cuentas DBA, cuentas privilegiadas y la cuenta de la aplicación.

Estas restricciones no suelen formar parte de las capacidades de la base de datos nativa y podrían incluir:

  • Impedir que las cuentas con privilegios accedan a esquemas, tablas u objetos a los que no deberían acceder. Por ejemplo, las cuentas de DBA normalmente no deberían acceder a los datos.
  • Impedir el acceso a una cuenta desde programas o máquinas que no deberían acceder a ella. Por ejemplo, solo el programa de aplicación y el servidor de aplicaciones deben acceder a la cuenta de la aplicación.
  • Impedir el acceso a una cuenta los días y horas en que no debería estar en uso.
  • Impedir que las cuentas accedan a más datos de los esperados (limitación de velocidad)
  • Hacer cumplir la separación de funciones al exigir al personal de seguridad que preautorice ciertas actividades privilegiadas.
  • Este requisito requiere una solución para implementar, ya que va más allá de los controles preventivos integrados en la base de datos. La aplicación de controles preventivos a las bases de datos plantea el riesgo operativo de bloquear la actividad legítima. Por lo tanto, la implementación de tales medidas debe realizarse cuidadosamente siguiendo las mejores prácticas apropiadas para minimizar el potencial de interrupciones

Fecha actualización el 2021-09-15. Fecha publicación el 2021-09-15. Categoria: ciberseguridad Autor: Oscar olg Mapa del sitio Fuente: helpnetsecurity