Seguridad de la base de datos

format_list_bulleted Contenido keyboard_arrow_down
ImprimirCitar

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 riesgos de confidencialidad, integridad y disponibilidad. Implica varios tipos o categorías de controles, como técnicos, procedimentales o administrativos, y físicos.

Los riesgos de seguridad para los sistemas de bases de datos incluyen, por ejemplo:

  • Actividad o uso indebido no autorizado o no deseado por usuarios autorizados de bases de datos, administradores de bases de datos o administradores de redes/sistemas, o por usuarios o hackers no autorizados (por ejemplo, acceso inapropiado a datos, metadatos o funciones sensibles dentro de bases de datos, o cambios inapropiados en los programas de bases de datos, estructuras o configuraciones de seguridad);
  • Infecciones de malware que causan incidentes como el acceso no autorizado, la fuga o la divulgación de datos personales o propietarios, la eliminación o el daño a los datos o programas, la interrupción o denegación del acceso autorizado a la base de datos, los ataques contra otros sistemas y el incumplimiento imprevisto de los servicios de bases de datos;
  • Sobrecargas, limitaciones de rendimiento y cuestiones de capacidad, lo que da lugar a la incapacidad de los usuarios autorizados de utilizar las bases de datos según lo previsto;
  • Daño físico a los servidores de bases de datos causados por incendios o inundaciones de la sala de computadoras, sobrecalentamiento, relámpagos, derrames accidentales de líquidos, descarga estática, desglose electrónico/insuficiencias de equipación y obsolescencia;
  • Efectivos de diseño y errores de programación en bases de datos y los programas y sistemas asociados, creando diversas vulnerabilidades de seguridad (por ejemplo, la escalada de privilegios no autorizada), la pérdida/corrupción de datos, la degradación del rendimiento, etc.;
  • Corrupción de datos y/o pérdida causada por la entrada de datos o comandos inválidos, errores en procesos de administración de bases de datos o sistemas, sabotaje/daño criminal, etc.

Ross J. Anderson ha dicho a menudo que, por su naturaleza, las bases de datos de gran tamaño nunca estarán libres de abusos por violaciones de seguridad; si un sistema de gran tamaño está diseñado para facilitar el acceso, se vuelve inseguro; si se hace hermético, se vuelve imposible de usar. Esto a veces se conoce como la regla de Anderson.

Existen muchas capas y tipos de control de seguridad de la información que son apropiados para las bases de datos, entre ellos:

  • Control de acceso
  • Auditoría
  • Autenticación
  • Encryption
  • Controles de integridad
  • Respaldos
  • Seguridad de la aplicación


Las bases de datos se han protegido en gran medida contra los piratas informáticos mediante medidas de seguridad de red, como cortafuegos y sistemas de detección de intrusiones basados en la red. Si bien los controles de seguridad de red siguen siendo valiosos en este sentido, la protección de los propios sistemas de bases de datos, así como de los programas, funciones y datos que contienen, se ha vuelto sin duda más crítica a medida que las redes se abren cada vez más 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 a 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 estándares y diseños de seguridad "de referencia" que detallan las medidas básicas de control de seguridad para sus sistemas de bases de datos. Estos pueden reflejar requisitos generales de seguridad de la información u obligaciones impuestas por las políticas de seguridad de la información corporativa y las leyes y regulaciones aplicables (por ejemplo, en relación con la privacidad, la gestión financiera y los sistemas de informes), junto con buenas prácticas de seguridad de bases de datos generalmente aceptadas (como el fortalecimiento adecuado 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 suelen especificar funciones adicionales de administración y gestión de seguridad (como la administración y la generación de informes de los derechos de acceso de los usuarios, la gestión y el análisis de registros, la replicación/sincronización de bases de datos y las copias de seguridad) junto con varios controles de seguridad de la información impulsados por el negocio dentro de los programas y funciones de bases de datos (por ejemplo, la validación de la entrada de datos y los registros de auditoría). Además, varias actividades relacionadas con la seguridad (controles manuales) normalmente se incorporan a los procedimientos, directrices, etc. relacionados con el diseño, el desarrollo, la configuración, el uso, la gestión y el mantenimiento de bases de datos.

Privilegios

Hay dos tipos de privilegios importantes en relación con la seguridad de la base de datos dentro del entorno de la misma: los privilegios del sistema y los privilegios de objeto.

Privilegios del sistema

Los privilegios del sistema permiten que un usuario local realice acciones administrativas en una base de datos.

Privilegios de objetos

Los privilegios de objeto permiten el uso de ciertas operaciones en objetos de base de datos según lo autorizado por otro usuario. Algunos ejemplos incluyen: uso, selección, inserción, actualización y referencias.

Privilegios mínimos

Las bases de datos que se encuentran bajo control interno (es decir, los 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 o una mirada fresca) 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 o el código del trabajo que se está realizando. Por lo general, el papel del desarrollador es pasar el código a un administrador de bases de datos; sin embargo, dados los recortes que han resultado de la crisis económica, es posible que no haya un administrador de bases de datos disponible. Si no hay un administrador de bases de datos involucrado, es importante, como mínimo, que un colega realice una revisión del código. Esto garantiza que el papel del desarrollador esté claramente separado.

Otro punto de control interno es la adhesión al principio de proporcionar la menor cantidad de privilegios, especialmente en producción. Para permitir que los desarrolladores tengan más acceso para realizar su trabajo, es mucho más seguro utilizar la suplantación de identidad para las excepciones que requieren privilegios elevados (por ejemplo, EXECUTE AS o sudo para hacerlo temporalmente). A menudo, los desarrolladores pueden descartar esto como una "carga adicional" mientras están en camino a la gloria de la codificación. Sin embargo, tenga en cuenta que los administradores de bases de datos 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.

Evaluaciones de vulnerabilidad para gestionar el riesgo y el cumplimiento

Una técnica para evaluar la seguridad de las bases de datos consiste en realizar evaluaciones de vulnerabilidad o pruebas de penetración en la base de datos. Los evaluadores intentan encontrar vulnerabilidades de seguridad que podrían utilizarse para vencer o eludir los controles de seguridad, entrar en 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, utilizar análisis de vulnerabilidades automatizados para buscar configuraciones incorrectas de los controles (a menudo denominadas "desviaciones") 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 permanecen sin reconocer ni abordar.

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 objetos dentro de la base de datos. Los objetos de la base de datos pueden incluir tablas u otros objetos enumerados en el vínculo Tabla. En este proceso se tienen en cuenta los permisos otorgados para los comandos del lenguaje SQL sobre los objetos. La supervisión del cumplimiento es similar a la evaluación de vulnerabilidades, excepto que los resultados de las evaluaciones de vulnerabilidades generalmente impulsan los estándares de seguridad que conducen al programa de supervisión continua. Básicamente, la evaluación de vulnerabilidades es un procedimiento preliminar para determinar el riesgo, mientras que un programa de cumplimiento es el proceso de evaluación de riesgos en curso.

El programa de cumplimiento debe tener en cuenta cualquier dependencia a nivel del software de la aplicación, ya que los cambios a nivel de la base de datos pueden tener efectos en el software de la aplicación o en el servidor de la aplicación.

Abstracció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.

Supervisión de la actividad de base de datos (DAM)

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 mediante el análisis del tráfico de protocolo (SQL) a través de la red, o mediante la observación de la actividad de la base de datos local en cada servidor mediante agentes de software, o ambas cosas. 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 capturar esta información de una manera que no puede ser deshabilitada por el administrador de la base de datos, 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 crear un patrón normal que se utilice para detectar actividad anómala que podría indicar una intrusión. Estos sistemas pueden proporcionar un registro de auditoría de base de datos completo además de los mecanismos de detección de intrusiones, y algunos sistemas también pueden proporcionar protección finalizando las sesiones de usuario o poniendo en cuarentena a los usuarios que demuestren un comportamiento sospechoso. Algunos sistemas están diseñados para admitir la separación de funciones (SOD), que es un requisito típico de los auditores. La SOD requiere que los administradores de bases de datos, que normalmente se supervisan como parte de la DAM, no puedan deshabilitar o alterar la funcionalidad de la DAM. Esto requiere que el registro de auditoría de la DAM se almacene de forma segura en un sistema separado que no esté administrado por el grupo de administración de bases de datos.

Auditoría nativa

Además de utilizar herramientas externas para la supervisión o auditoría, las capacidades de auditoría de bases de datos nativas también están disponibles para muchas plataformas de bases de datos. Los registros de auditoría nativos se extraen de forma regular y se transfieren a un sistema de seguridad designado al que los administradores de bases de datos no tienen acceso (o no deberían tenerlo). Esto garantiza un cierto nivel de segregación de funciones que puede proporcionar evidencia de que los registros de auditoría nativos no fueron modificados por administradores autenticados, y deben ser realizados por un grupo de administradores de bases de datos senior orientado a la seguridad con derechos de lectura en producción. Activar los registros nativos afecta el rendimiento del servidor. Generalmente, los registros de auditoría nativos de las bases de datos no proporcionan controles suficientes para hacer cumplir la separación de funciones; por lo tanto, las capacidades de monitoreo basadas en host a nivel de módulo de red y/o kernel proporcionan un mayor grado de confianza para la investigación forense y la preservación de la evidencia.

Procesos y procedimientos

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 las cuentas utilizadas por procesos inmediatos. Para las cuentas individuales, un sistema de autenticación de dos factores mejora la seguridad, pero agrega complejidad y costos. 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 vulneración.

En combinación con un programa de seguridad de bases de datos sólido, un programa de recuperación de desastres adecuado puede garantizar que el servicio no se interrumpa durante un incidente de seguridad o cualquier incidente que provoque una interrupción del entorno de la base de datos principal. Un ejemplo es la replicación de las bases de datos principales en sitios ubicados en diferentes regiones geográficas.

Después de que ocurre un incidente, se pueden utilizar análisis forenses de bases de datos para determinar el alcance de la violación y para identificar los cambios apropiados en los sistemas y procesos.

Véase también

  • Base de datos negativa
  • Firewall de la base de datos
  • FIPS 140-2 estándar federal para autenticar un módulo de criptografía
  • Base de datos privada virtual

Referencias

  1. ^ "¿Qué es la seguridad de bases de datos?". IBM. Retrieved 21 de enero 2024.
  2. ^ Porter, H.; Hirsch, A. (10 de agosto de 2009). "Nine fue despedido por violar la base de datos de la tarjeta de identificación central". The Guardian. Retrieved 21 de enero 2024.
  3. ^ Stephens, Ryan (2011). Los Sams se enseñan SQL en 24 horas. Indianapolis, Ind: Sams. ISBN 9780672335419.
  4. ^ "Las mejores prácticas de seguridad de la base de datos". technet.microsoft.com. Archivado desde el original en 2016-09-15. Retrieved 2016-09-02.
  5. ^ Seema Kedar (2007). Sistemas de gestión de bases de datos. Technical Publications. p. 15. ISBN 978-81-8431-584-4. Retrieved 21 de enero 2024.

Más lectura

  • "Guías de Implementación Técnica de Seguridad". El intercambio cibernético DoD. 2021. La Agencia de Sistemas de Información de Defensa 2021 guías de implementación técnica.
Más resultados...
Tamaño del texto:
undoredo
format_boldformat_italicformat_underlinedstrikethrough_ssuperscriptsubscriptlink
save