security - una - Acceso a datos en bases de datos de producción internas desde un servidor web en DMZ

zona desmilitarizada(informática) (7)

Estoy trabajando en un sitio web externo (en DMZ) que necesita obtener datos de nuestra base de datos de producción interna.

Todos los diseños que he creado son rechazados porque el departamento de red no permitirá que una conexión de ningún tipo (WCF, Oracle, etc.) entre dentro de la DMZ.

Las sugerencias que provienen del lado de la red generalmente se clasifican en dos categorías:

1) Exportar los datos requeridos a un servidor en la DMZ y exportar registros modificados / insertados eventualmente de alguna manera, o

2) Realice una encuesta desde el interior y pregunte continuamente a un servicio en la DMZ si tiene alguna solicitud que deba repararse.

Soy reacio a la sugerencia 1 porque no me gusta la idea de una base de datos en la DMZ. La opción 2 parece una cantidad ridícula de complicación adicional por la naturaleza de lo que se está haciendo.

¿Son estas las únicas soluciones legítimas? ¿Hay una solución obvia que me falta? ¿Es práctico el decreto "No hay conexiones desde DMZ"?

Edición: una línea que escucho constantemente es que "ninguna empresa grande permite que un sitio web se conecte para obtener datos de producción en vivo. Por eso envían correos electrónicos de confirmación". ¿Es así realmente como funciona?

¿Por qué no replicas tus servidores de bases de datos? Puede asegurarse de que la conexión se realice desde los servidores internos a los servidores externos y no a la inversa.

Una forma es usar el marco de sincronización de ms: puede crear un servicio de Windows simple que pueda sincronizar los cambios de la base de datos interna a su base de datos externa (que puede residir en un servidor de db separado) y luego usarlo en su sitio web público. La ventaja es que su lógica de sincronización puede filtrar los datos confidenciales y mantener solo las cosas que son realmente necesarias. Y dado que todo el control de los datos estará en sus servidores internos (PULSAR los datos en lugar de extraerlos) No creo que TI tenga un problema con eso.

La conexión que se forma nunca entra, está fuera, lo que significa que no es necesario abrir ningún puerto.

Antes de hablar sobre su problema en particular, quiero lidiar con la Actualización que proporcionó.

No he trabajado para una empresa "grande", aunque es difícil juzgar lo grande sin un contexto, pero he creado mi parte de aplicaciones web para el departamento sin fines de lucro y el departamento universitario en el que solía trabajar. En ambas situaciones, siempre me he conectado a la base de datos de producción que está en la red interna desde el servidor web en la DMZ. Estoy bastante seguro de que muchas compañías grandes hacen esto también; piense, por ejemplo, en cómo se configura la arquitectura de Sharepoint: servidores de indexación back-end, bases de datos, etc., que están conectados a través de servidores web frontales ubicados en la DMZ.

Además, la práctica de enviar correos electrónicos de confirmación, que creo que usted hace referencia a las confirmaciones cuando se registra en un sitio, generalmente no se ocupa de la seguridad. Son más un método para verificar que un usuario haya ingresado una dirección de correo electrónico válida.

Ahora, con eso fuera del camino, veamos su problema. Desafortunadamente, aparte de las dos soluciones que presentaste, no puedo pensar en ninguna otra forma de hacer esto. Aunque algunas cosas que usted podría querer pensar:

Soluciones 1:

Dependiendo de la sensibilidad de los datos con los que necesita trabajar, extraerlos en un servidor en la DMZ, ya sea utilizando un servicio o algún tipo de software de sincronización automática, va en contra del sentido común de la seguridad básica. Lo que has hecho es mover los datos de un servidor detrás de un firewall a uno que está frente a él. También podrían permitirle acceder al servidor interno de db desde la DMZ.

Solución 2:

No soy experto en redes, así que corríjame si me equivoco, pero un mecanismo de sondeo todavía requiere algún tipo de comunicación desde el servidor web para informar al servidor de la base de datos que necesita algún tipo de datos, lo que significa que un puerto debe estar abierto y, de nuevo, también podría decirles que le permitan acceder a la base de datos interna sin problemas, porque realmente no ha agregado ninguna seguridad adicional con este método.

Por lo tanto, espero que esto ayude, al menos, a proporcionarle algunos argumentos que le permitan acceder a los datos directamente. A mi parecer, hay muchos conceptos erróneos en su departamento de red sobre el aspecto que debería tener una arquitectura de aplicación web respaldada por una base de datos segura.

Esto es lo que podrías hacer ... es un poco exagerado, pero debería funcionar ...

Escriba un servicio que se encuentra en el servidor en la DMZ. Escuchará en tres puertos, A, B y C (elija cualquier número de puerto que tenga sentido). Llamaré a esto la aplicación del túnel DMZ.

Escribe otro servicio que viva en cualquier lugar de la red interna. Se conectará a la aplicación del túnel DMZ en el puerto B. Una vez establecida esta conexión, la aplicación del túnel DMZ ya no necesita escuchar en el puerto B. Esta es la "conexión de control".

Cuando algo se conecta al puerto A de la aplicación del túnel DMZ, enviará una solicitud a través de la conexión de control para una nueva base de datos / cualquier conexión. La aplicación del túnel interno responderá conectándose al recurso interno. Una vez que se establezca esta conexión, se conectará de nuevo a la aplicación del túnel DMZ en el puerto C.

Después de verificar posiblemente algunos tokens (esta parte depende de usted), la aplicación del túnel DMZ enviará datos entre las conexiones que recibió en el puerto A y C. De hecho, tendrá un proxy TCP transparente creado desde dos servicios que se ejecutan en el DMZ y en la red interna.

Y, para la mejor parte, una vez hecho esto, puede explicar lo que hizo a su departamento de TI y observar sus caras cuando se dan cuenta de que no violó la letra de su política de seguridad, pero sigue siendo productivo. Te lo digo, ellos lo odiarán.

Estoy sobre todo con Ken Ray en esto; sin embargo, parece haber alguna información faltante. A ver si entiendo esto bien:

Tienes una aplicación web.
Parte de esa aplicación web necesita mostrar datos de un servidor de producción diferente (no el que normalmente respalda su sitio).
Los datos que desea / necesita son manejados por una aplicación completamente diferente internamente.
Estos datos son críticos para el flujo normal de su negocio y solo un conjunto limitado debe estar disponible para el mundo exterior.

Si estoy en el buen camino, tendría que decir que estoy de acuerdo con su departamento de TI y que tampoco le permitiré acceder directamente a ese servidor.

Simplemente tome la opción 1. Haga que el servidor de producción exporte los datos que necesita a una ubicación de descarga comúnmente accesible. Haga que el otro servidor de la base de datos (uno en la DMZ) recoja los datos y los importe de manera regular. Finalmente, haga que su aplicación web SOLAMENTE hable con el servidor db en el dmz.

Dada la cantidad de gente que construye sitios en estos días, también me resistiría a abrir un puerto sql desde el dmz al servidor web en cuestión. Francamente, podría convencerme de abrir la conexión si estuviera seguro de que 1. solo usó procs almacenados para acceder a los datos que necesita; 2. la información de la cuenta utilizada para acceder a la base de datos estaba encriptada y completamente restringida a solo ejecutar esos procesos; 3. esos procs tenían cero sql dinámico y estaban limitados a selecciones; 4. Su código fue construido a la derecha.

Una persona normal de TI probablemente no estaría calificada para responder todas esas preguntas. Y si esta base de datos fuera de un tercero, apostaría a que perdería soporte si comenzara a acceder desde fuera de su aplicación normal.

Lo siento, pero su departamento de redes está en crack o algo así, claramente no entienden cuál es el propósito de una DMZ. Para resumir: hay tres "áreas": el mundo exterior grande y malo, tu mundo interior puro y virginal y la DMZ segura, conocida y confiable.

Las reglas son:

Las conexiones desde el exterior solo pueden llegar a los hosts en la DMZ y en puertos específicos (80, 443, etc.);
Las conexiones desde el exterior hacia el interior están completamente bloqueadas;
Las conexiones desde el interior a la DMZ o al exterior son finas y elegantes;
Solo los hosts en la DMZ pueden establecer conexiones con el interior, y nuevamente, solo en puertos bien conocidos y permitidos.

El punto cuatro es el que no han entendido: la política de "no hay conexiones desde la DMZ" está mal dirigida.

Pregúnteles "¿Cómo funciona nuestro sistema de correo electrónico, entonces?" Supongo que tiene un servidor de correo corporativo, tal vez intercambio, y las personas tienen clientes que se conectan a él. Pídales que expliquen cómo funciona su correo electrónico corporativo, con acceso al correo electrónico de Internet, y que cumple con su política.

Lo siento, realmente no te da una respuesta.

Si no se pueden aplicar todas las soluciones de desarrollo debido a la restricción de ingeniería del sistema en DMZ, entonces dales la pelota.

Coloque su sitio web en intranet y dígales '' Ahora necesito conexiones HTTP entrantes: 80 o HTTPS: 443 para esas aplicaciones. Configure lo que desea: proxies inversos, ISA Server , protocolos break, SSL ... Adaptaré mi aplicación si es necesario. ''

Acerca de ISA, supongo que obtuvieron una si tienes intercambio con conexiones externas.

Muchas empresas están optando por esta solución cuando un recurso debe compartirse entre la intranet y el público.

Configurar una red específica e intranet con reglas de alta seguridad es la mejor manera de facilitar la administración, la integración y la implementación. Lo que es más fácil es bien conocido, lo que se sabe está masterizado: menos violaciones de seguridad.

Cada vez más ingenieros de sistemas (como las minas) prefieren mantener una red de intranet con una pequeña ''brecha de seguridad'' como HTTP que abrir otros protocolos y puertos.

Por cierto, si conocieran los servicios de WCF, habrían aceptado esta solución. Esta es la solución más segura si está bien diseñada.

Personalmente, utilizo estos dos métodos: Servicios TCP (HTTP o no) e ISA Server.

Soy un arquitecto de seguridad en una firma financiera de Fortune 50. Tuvimos estas mismas conversaciones. No estoy de acuerdo con su grupo de red. Entiendo su angustia, y entiendo que les gustaría una mejor solución, pero la mayoría de los lugares no optan por las mejores opciones (debido a la ignorancia de su parte [es decir, la gente de la red no es usted]).

Dos opciones si son difíciles de configurar: puede usar una solución de proxy SQL como greensql (no trabajo para ellos, solo los conozco) simplemente son greensql dot com.

El enfoque al que se refieren al uso que hacen la mayoría de las "grandes organizaciones" es un modelo web escalonado. Cuando tenga un servidor web front-end (accesible por el público en general), un nivel intermedio (capa de aplicación o servicios donde se producen los procesos reales) y un nivel de base de datos. El nivel medio es lo único que puede comunicarse con el nivel de la base de datos. En mi opinión, este modelo es óptimo para la mayoría de las grandes organizaciones. PERO una vez dicho esto, la mayoría de las grandes organizaciones se encontrarán con un producto proporcionado por un proveedor que no es compatible con un nivel medio, se desarrollaron sin un nivel medio y la transición requiere recursos de desarrollo de los que no tienen que contar para desarrollar los servicios web de nivel medio. O simplemente no hay prioridad en algunas compañías para ir por esa ruta.

Es un área gris, no hay un derecho sólido o incorrecto en ese sentido, por lo que si están hablando en términos de finalidad, entonces están claramente equivocados. Aplaudo su celo, como profesional de seguridad entiendo de dónde vienen. PERO, tenemos que permitir que las empresas funcionen de manera segura. Ese es el reto y el reto que siempre trato de arrojarme a mí mismo. ¿Cómo puedo ofrecer a mis clientes (a mis desarrolladores, a mis administradores, a mis bases de datos, a los usuarios de negocios) lo que quieren (dentro de lo razonable y, si se lo digo a alguien, siempre trato de ofrecer una alternativa que satisfaga la mayoría de sus necesidades)?

Sinceramente, debería ser una conversación abierta. Aquí es donde creo que puedes conseguir algo de espacio, pídeles que amenacen el riesgo que buscan mitigar. Pídales que ofrezcan soluciones alternativas que permitan que sus aplicaciones web funcionen. Si están diciendo que no pueden hablar, póngales la responsabilidad de proporcionarles una solución. Si no pueden, entonces usted por defecto funciona. Sitio en el que abre conexiones desde el dmz al db SOLAMENTE para los puertos aprobados. Hágales saber que DMZ es para ofrecer servicios externos. Los servicios externos no son buenos sin datos internos para nada más que soluciones de transferencia de archivos potenciales.

Sólo mis dos centavos, espero que este comentario ayude. Y trata de ser fácil con mis hermanos de seguridad. Tenemos un poco de experiencia equivocada en nuestro rebaño que se aferra a algunas formas antiguas de hacer las cosas. A medida que el mundo evoluciona, la amenaza evoluciona, al igual que nuestro enfoque de la mitigación.