La seguridad de las bases de datos se refiere al uso de una amplia gama de controles de seguridad de la información para proteger las bases de datos contra compromisos de su confidencialidad, integridad y disponibilidad. [1] Implica varios tipos o categorías de controles, como los técnicos, procesales o administrativos, y físicos.
Los riesgos de seguridad para los sistemas de bases de datos incluyen, por ejemplo:
Ross J. Anderson ha dicho a menudo que, por su naturaleza, las grandes bases de datos nunca estarán libres de abusos por violaciones de seguridad; si un sistema grande está diseñado para facilitar el acceso, se vuelve inseguro; si se hace impermeable resulta imposible su uso. Esto a veces se conoce como regla de Anderson. [2]
Muchas capas y tipos de control de seguridad de la información son apropiados para las bases de datos, entre ellos:
Las bases de datos se han protegido en gran medida contra los piratas informáticos mediante medidas de seguridad de la red , como firewalls y sistemas de detección de intrusos basados en la red . Si bien los controles de seguridad de la red siguen siendo valiosos a este respecto, proteger los propios sistemas de bases de datos y los programas/funciones y datos que contienen se ha vuelto más crítico a medida que las redes están cada vez más abiertas a un acceso más amplio, en particular el acceso desde Internet. Además, los controles de acceso a sistemas, programas, funciones y datos, junto con las funciones asociadas de identificación de usuarios, autenticación y gestión de derechos, siempre han sido importantes para limitar y, en algunos casos, registrar las actividades de los usuarios y administradores autorizados. En otras palabras, estos son enfoques complementarios para la seguridad de las bases de datos, que funcionan tanto de afuera hacia adentro como de adentro hacia afuera, por así decirlo.
Muchas organizaciones desarrollan sus propios diseños y estándares de seguridad "básicos" que detallan las medidas básicas de control de seguridad para sus sistemas de bases de datos. Estos pueden reflejar requisitos u obligaciones generales de seguridad de la información impuestas por las políticas corporativas de seguridad de la información y las leyes y regulaciones aplicables (por ejemplo, en materia de privacidad, gestión financiera y sistemas de informes), junto con buenas prácticas de seguridad de bases de datos generalmente aceptadas (como el refuerzo apropiado de los sistemas subyacentes). y quizás recomendaciones de seguridad de los proveedores de software y sistemas de bases de datos pertinentes. Los diseños de seguridad para sistemas de bases de datos específicos generalmente especifican funciones adicionales de administración y gestión de seguridad (como administración e informes de derechos de acceso de usuarios, gestión y análisis de registros, replicación/sincronización de bases de datos y copias de seguridad) junto con varios controles de seguridad de la información impulsados por el negocio dentro de la base de datos. programas y funciones (por ejemplo, validación de entrada de datos y pistas de auditoría ). Además, normalmente se incorporan diversas actividades relacionadas con la seguridad (controles manuales) en los procedimientos, directrices, etc. relacionados con el diseño, desarrollo, configuración, uso, gestión y mantenimiento de bases de datos.
Dos tipos de privilegios son importantes en relación con la seguridad de la base de datos dentro del entorno de la base de datos: privilegios del sistema y privilegios de objetos.
Los privilegios del sistema permiten a un usuario local realizar acciones administrativas en una base de datos.
Los privilegios de objeto permiten el uso de ciertas operaciones en objetos de base de datos según lo autorice otro usuario. Los ejemplos incluyen: uso, selección, inserción, actualización y referencias. [3]
Las bases de datos que caen bajo controles internos (es decir, datos utilizados para informes públicos, informes anuales, etc.) están sujetas a la separación de funciones, lo que significa que debe haber una segregación de tareas entre desarrollo y producción. Cada tarea debe ser validada (mediante un recorrido por el código/ojos nuevos) por una tercera persona que no esté escribiendo el código real. El desarrollador de la base de datos no debería poder ejecutar nada en producción sin una revisión independiente de la documentación/código del trabajo que se está realizando. Normalmente, la función del desarrollador es pasar código a un DBA; sin embargo, dados los recortes resultantes de la crisis económica, es posible que no haya un DBA disponible. Si un DBA no está involucrado, es importante, como mínimo, que un par realice una revisión del código. Esto garantiza que el papel del desarrollador esté claramente separado. [ cita necesaria ]
Otro punto del control interno es el cumplimiento del principio de otorgar la menor cantidad de privilegios, especialmente en la producción. Para permitir a los desarrolladores más acceso para realizar su trabajo, es mucho más seguro utilizar la suplantación para excepciones que requieren privilegios elevados (por ejemplo, EJECUTAR AS o sudo para hacerlo temporalmente). A menudo, los desarrolladores pueden descartar esto como "gastos generales" en su camino hacia la gloria de la codificación. Sin embargo, tenga en cuenta que los DBA deben hacer todo lo que se considere responsable porque son los administradores de datos de facto de la organización y deben cumplir con las regulaciones y la ley. [4]
Una técnica para evaluar la seguridad de la base de datos implica realizar evaluaciones de vulnerabilidad o pruebas de penetración en la base de datos. Los evaluadores intentan encontrar vulnerabilidades de seguridad que podrían usarse para anular o eludir los controles de seguridad, ingresar a la base de datos, comprometer el sistema, etc. Los administradores de bases de datos o administradores de seguridad de la información pueden, por ejemplo, usar escaneos automatizados de vulnerabilidades para buscar configuraciones incorrectas de los controles (a menudo denominadas como 'deriva') dentro de las capas mencionadas anteriormente junto con vulnerabilidades conocidas dentro del software de la base de datos. Los resultados de dichos análisis se utilizan para reforzar la base de datos (mejorar la seguridad) y cerrar las vulnerabilidades específicas identificadas, pero otras vulnerabilidades a menudo no se reconocen ni se abordan.
En entornos de bases de datos donde la seguridad es crítica, la supervisión continua del cumplimiento de los estándares mejora la seguridad. El cumplimiento de la seguridad requiere, entre otros procedimientos, la gestión de parches y la revisión y gestión de permisos (especialmente públicos) otorgados a los objetos dentro de la base de datos. Los objetos de la base de datos pueden incluir tablas u otros objetos enumerados en el enlace Tabla. En este proceso se consideran los permisos otorgados para comandos del lenguaje SQL sobre objetos. El monitoreo del cumplimiento es similar a la evaluación de vulnerabilidades, excepto que los resultados de las evaluaciones de vulnerabilidad generalmente impulsan los estándares de seguridad que conducen al programa de monitoreo continuo. Esencialmente, la evaluación de la vulnerabilidad es un procedimiento preliminar para determinar el riesgo, donde un programa de cumplimiento es el proceso de evaluación de riesgos continua.
El programa de cumplimiento debe tener en cuenta cualquier dependencia en el nivel del software de la aplicación , ya que los cambios en el nivel de la base de datos pueden tener efectos en el software de la aplicación o en el servidor de la aplicación .
Los mecanismos de autenticación y autorización a nivel de aplicación pueden ser medios eficaces para proporcionar abstracción de la capa de base de datos. El principal beneficio de la abstracción es la capacidad de inicio de sesión único en múltiples bases de datos y plataformas. Un sistema de inicio de sesión único almacena las credenciales del usuario de la base de datos y se autentica en la base de datos en nombre del usuario. La abstracción es la idea de hacer que las ideas complejas sean más fáciles de entender.
Otra capa de seguridad de naturaleza más sofisticada incluye el monitoreo de la actividad de la base de datos en tiempo real , ya sea analizando el tráfico de protocolo (SQL) a través de la red, o observando la actividad de la base de datos local en cada servidor mediante agentes de software, o ambas. Se requiere el uso de agentes o registros nativos para capturar las actividades ejecutadas en el servidor de la base de datos, que normalmente incluyen las actividades del administrador de la base de datos. Los agentes permiten que esta información se capture de una manera que el administrador de la base de datos no puede deshabilitar, quien tiene la capacidad de deshabilitar o modificar los registros de auditoría nativos.
Se pueden realizar análisis para identificar vulnerabilidades conocidas o infracciones de políticas, o se pueden capturar líneas de base a lo largo del tiempo para construir un patrón normal utilizado para la detección de actividad anómala que podría ser indicativa de intrusión. Estos sistemas pueden proporcionar un seguimiento de auditoría integral de la base de datos además de los mecanismos de detección de intrusiones, y algunos sistemas también pueden brindar protección finalizando las sesiones de los usuarios y/o poniendo en cuarentena a los usuarios que demuestren un comportamiento sospechoso. Algunos sistemas están diseñados para soportar la separación de funciones (SOD), que es un requisito típico de los auditores. SOD requiere que los administradores de bases de datos que normalmente son monitoreados como parte del DAM no puedan deshabilitar ni alterar la funcionalidad del DAM. Esto requiere que la pista de auditoría DAM se almacene de forma segura en un sistema separado no administrado por el grupo de administración de la base de datos.
Además de utilizar herramientas externas para monitoreo o auditoría, las capacidades nativas de auditoría de bases de datos también están disponibles para muchas plataformas de bases de datos. Las pistas de auditoría nativas se extraen periódicamente y se transfieren a un sistema de seguridad designado al que los administradores de la base de datos no deben tener acceso. Esto garantiza un cierto nivel de segregación de tareas que puede proporcionar evidencia de que los administradores autenticados no modificaron las pistas de auditoría nativas y deben ser realizadas por un grupo de DBA senior orientado a la seguridad con derechos de lectura en producción. Activar el modo nativo afecta el rendimiento del servidor. Generalmente, las pistas de auditoría nativas de las bases de datos no proporcionan controles suficientes para imponer la separación de funciones; por lo tanto, las capacidades de monitoreo basadas en host a nivel de módulo de núcleo y/o red brindan un mayor grado de confianza para los análisis forenses y la preservación de evidencia.
Un buen programa de seguridad de bases de datos incluye la revisión periódica de los privilegios otorgados a las cuentas de usuario y a las cuentas utilizadas por los procesos inmediatos. Para cuentas individuales, un sistema de autenticación de dos factores mejora la seguridad pero añade complejidad y costo. Las cuentas utilizadas por procesos automatizados requieren controles adecuados en torno al almacenamiento de contraseñas, como cifrado suficiente y controles de acceso para reducir el riesgo de compromiso.
Junto con un programa sólido de seguridad de la base de datos, un programa apropiado de recuperación ante desastres puede garantizar que el servicio no se interrumpa durante un incidente de seguridad o cualquier incidente que resulte en una interrupción del entorno de la base de datos principal. Un ejemplo es el de la replicación de las bases de datos primarias en sitios ubicados en diferentes regiones geográficas. [5]
Después de que ocurre un incidente, se pueden emplear análisis forenses de bases de datos para determinar el alcance de la infracción e identificar los cambios apropiados en los sistemas y procesos.