Protección de la base de datos: externa e interna

3

Mi empresa está utilizando una configuración de base de datos extraña y realmente no puedo entender lo que está agregando en términos de seguridad.

Nuestra configuración

Outside World [Firewall] DMZ - Servidor web [Firewall] Base de datos externa [Firewall] Base de datos interna

  • El servidor web solo puede comunicarse con la base de datos externa.
  • No se puede acceder a la base de datos externa desde el exterior. Por ejemplo, no puedo acceder a él desde mi casa, incluso si conozco la dirección y tengo un nombre de usuario / contraseña válidos.
  • La base de datos interna no se puede acceder desde el exterior también.

Por lo tanto, la única diferencia entre la base de datos externa e interna es que el servidor web puede acceder a la externa pero no a la interna.

Nuestro flujo de datos

Cuando un usuario ingresa información en nuestro sitio web, esa información se envía a nuestro servidor web. El servidor web luego inserta esa información en la base de datos externa. Luego, un trabajo se ejecutará periódicamente y tomará los nuevos datos de la Base de datos externa y los insertará en la Base de datos interna. Luego, el empleado puede modificar los datos en la base de datos interna y estas modificaciones se sincronizarán nuevamente en la Base de datos externa.

Mi pregunta

¿Qué agrega desde un punto de vista de seguridad para tener una base de datos externa e interna?

Tendría sentido si se pudiera acceder a una base de datos desde el exterior, pero dado que ambas están detrás del firewall, ¿qué cambia si las insertamos directamente en la Base de Datos Interna? De todos modos, si insertamos algo en la base de datos externa, también se sincronizará con la base de datos interna.

Mi problema

Nos metimos en un complicado lío de sincronización con trabajos que se ejecutan en todas partes, datos duplicados en todas partes y con eso vienen los errores tradicionales. Algunos trabajos no se actualizan cuando actualizamos el esquema, los datos ya no son los mismos entre todas las bases de datos y terminamos con una tonelada de datos que ya no sabemos si es la copia más reciente o no, cuál es válida y Veo todos esos problemas como una gran pérdida de tiempo y dinero.

Ahora, la gran razón por la que lo hicimos tan complicado es porque: "Es más seguro". ¿Realmente es así porque no veo la diferencia entre el servidor web que inserta los datos directamente en una base de datos y el uso de múltiples trabajos para sincronizar esos datos en todas partes?

    
pregunta Gudradain 29.01.2016 - 23:34
fuente

2 respuestas

3

Hay situaciones en las que se usa una base de datos externa para almacenar información temporal que se "extrae" y no "se empuja" a través de una conexión de firewall de una sola dirección hacia una base de datos interna más grande, luego se eliminan los datos de la externa. . El propósito de esto es reducir el número de registros que pueden ser robados en un momento dado y permitir que los datos continúen fluyendo hacia el sistema externo. Dicho esto, su situación puede ser completamente diferente. Si los datos son iguales en ambos lados, es probable que no sea por este motivo, pero un propósito para hacer algo como esto es porque puede proporcionar una capa adicional de defensa en profundidad para las bases de datos.

Piense en el caso en el que los ataques de inyección de SQL pasan por un servidor front-end y logran que un atacante, a veces con acceso completo a la shell, acceda a la base de datos conectada a la aplicación web. En el caso de una sola base de datos, el atacante obtiene todo, incluidos todos los registros. En el caso que mencioné anteriormente, el atacante solo tiene acceso a un pequeño subconjunto de registros transaccionales por el tiempo que tienen acceso al sistema (es de esperar que esto se descubra y que la línea de tiempo sea muy breve). En cualquier caso, esa es una de las razones por las que podrías hacer algo como esto. Una vez más, su caso puede variar.

    
respondido por el Trey Blalock 30.01.2016 - 00:12
fuente
1

Bueno, la pregunta obvia es: ¿pueden los recursos de acceso a la base de datos externa en la red en la que se encuentra la base de datos interna?

Si la base de datos externa está aislada de la LAN, eso significa que un atacante que termina ingresando no solo en los registros de la base de datos externa, sino también en el sistema operativo principal de la base de datos externa, no puede acceder más lejos a la red.

Si el servidor web estuviera conectado directamente a la base de datos interna, entonces si obtuvieran acceso al sistema operativo desde la base de datos interna, podrían atacar al resto de la LAN libremente.

Para el ejemplo de SQL Server, su peor caso es

  • inyección SQL en el servidor
  • Use xp_cmdshell para ejecutar el código en el símbolo del sistema del servidor
  • Averigüe que el servidor SQL se está ejecutando como administrador de dominio
  • esperar 6p.m. el último día laborable antes de un largo fin de semana
  • Roba TODO
  • Destruye todas las copias de seguridad que aún están en línea
  • Limpie todas las unidades en toda la red
  • Borre las configuraciones de todos los dispositivos de red que usan contraseñas predeterminadas (SAN, conmutadores, enrutadores, cortafuegos, etc.)
respondido por el Anti-weakpasswords 31.01.2016 - 05:56
fuente

Lea otras preguntas en las etiquetas