¿Qué tan segura es esta arquitectura?

Question

Estoy construyendo un sistema que necesita para recoger algunos datos confidenciales de los usuarios a través de conexión web segura, almacenar de forma segura en el servidor para el descifrado tarde automatizado y la reutilización. El sistema también debe permitir al usuario ver una parte de los datos protegidos (por ejemplo, *****ze) y / o cambiar por completo desde la web. El sistema debe proporcionar un nivel razonable de seguridad.

Yo estaba pensando en la siguiente infraestructura:

Aplicación (web) Servidor 1

1. servidor Web con soporte adecuado TLS para las conexiones de Internet seguras.

2. Usar el algoritmo de clave pública (por ejemplo, RSA) a encriptar los datos sensibles de usuario introducido y enviarlo a servidor de aplicaciones 2 a través unidireccional saliente asegurado canal (Por ejemplo ssh-2) sin almacenarlo en cualquier parte de cualquiera de servidor de aplicaciones 1 o DB Servidor 1 .

3. El uso fácil de la contraseña dependiente de clave simétrica algoritmo para cifrar alguna parte de los datos introducidos (por ejemplo, últimos letras / dígitos) y tienda que en el DB Server 1 para más adelante recuperación por servidor de aplicaciones 1 durante sesión de usuario de la web.

4. Reutilización el paso 2 para la modificación de datos por el usuario a través de web.

DB Server 1

1. tienda sin garantía usuario no sensibles datos.
2. Tienda alguna parte del delicada datos de usuario cifrados en servidor de aplicaciones 1 (Ver paso 3 anterior)

servidor de aplicaciones 2

1. no NUNCA enviar nada A servidor de aplicaciones 1 o DB Server 1 .
2. Recibir usuario cifrada sensible datos de servidor de aplicaciones 1 y almacenarla en DB Server 2 .
3. Recuperar encriptado de usuario datos sensibles de DB Server 2 de acuerdo con los horarios locales, descifrarlo utilizando la clave privada (Ver servidor de aplicaciones 1 , paso 2) almacenado localmente en servidor de aplicaciones 2 con la gestión de claves adecuado.

DB Server 2

datos sensibles
1. cifrado de la tienda por el usuario (ver App Server 2 , paso 2)

Si bien Aplicación (web) Servidor 1 o DB Server 1 o ambos están comprometidos a continuación atacante no será capaz de obtener los datos confidenciales del usuario (ya sea o no cifrado ). Todo el atacante tendrá acceso a los algoritmos de clave pública y encriptación que son bien conocidos de todos modos. Sin embargo atacante será capaz de modificar el servidor web para obtener actualmente conectado contraseñas de los usuarios en texto plano y descifrar parte del usuario de datos confidenciales almacenados en la base de datos del Servidor 1 (ver servidor de aplicaciones 1 , el paso 3), que yo no' t consideran como un gran problema. Atacante será capaz de (a través de la modificación del código) los datos confidenciales de los usuarios también interceptar introducidos por los usuarios desde la web durante el ataque potencial. Más tarde me considero como un riesgo más alto, pero a condición de que es difícil (¿es?) Para modificar el código atacante sin que alguien notar que supongo que no debería preocuparse mucho al respecto.

Si servidor de aplicaciones 2 y la clave privada se vean comprometidas a continuación atacante tendrá acceso a todo, pero servidor de aplicaciones 2 o DB Server 2 son no web frente a lo que no debería ser un problema.

¿Qué tan segura es esta arquitectura? Es mi entendimiento de cómo los algoritmos de cifrado y protocolos garantizados funcionan correctamente?

Gracias!

Answer 1

No creo que puedo dar una respuesta adecuada, porque no estoy seguro de que el objetivo de su sistema es clara. Aunque aprecio que conocer la opinión de un diseño, que es un poco difícil sin un propósito.

Yo sugeriría a que esto, sin embargo:

Totalmente de documentar y analizar su modelo de amenazas primera

Es necesario llegar a una lista fija de líneas duras de todos los posibles escenarios de ataque. atacantes locales, etc, que está tratando de proteger contra? También dice cosas como 'con la gestión de claves adecuado'; sin embargo, esta es una de las cosas más difíciles de hacer. Así que no sólo asumen puede obtener este derecho; planea plenamente cómo va a hacer esto, la vinculación específica a que se evitará que los ataques de.

La razón por la que tiene que hacer un modelo de amenaza, es que se tendrá que determinar en qué ángulos va a ser vulnerable; ya que este será el caso.

Yo también sugieren que, aunque la teoría es buena; cripto en aplicación es también muy crítico. No asuma que va a hacer las cosas correctamente, que realmente necesita para cuidar de dónde proceden de números aleatorios, y otras cosas.

Yo sé que es un poco vago, pero yo creo que por lo menos dar con modelo formal y fuerte amenaza, será muy útil para usted.

Answer 2

Hasta aquí todo bien. Usted está bien en su camino a una arquitectura muy seguro. Hay otras preocupaciones, tales como cortafuegos, políticas de contraseñas, registro, monitoreo y alerta a considerar, pero todo lo que describieron hasta ahora es muy sólido. Si los datos son lo suficientemente sensibles, considere una auditoría de tercera parte de su seguridad.

Answer 3

No recomendaría el uso de cualquier forma de clave pública para comunicarse desde su servidor web a su servidor de aplicaciones. Si se controla tanto el sistema sólo un sistema secreto regular de cifrado. Usted sabe la identidad del servidor de aplicación, por lo que mantener la llave de seguridad no es un problema. Si alguna vez tiene que cambiar o actualizar la clave secreta simplemente de forma manual para evitar que se filtre a través de una conexión.

Lo que sería más cuidado es dirección de la transferencia de datos desde el servidor en su DMZ, que sólo debe ser su servidor web, a aquellas cajas que residen internamente a la red. Cada vez es más común que los dominios legítimos para ser comprometidas para distribuir software malicioso a los usuarios que visitan. Eso es malo, pero si el malware eran a su vez en la sala de su red en lugar de solamente hacia fuera para sus usuarios entonces su negocio sería completamente manguera.

Además, no me veo nada acerca de la prevención de la inyección de SQL o endurecimiento del sistema / parches para evitar la distribución de malware. Esta debe ser su primera y más importante consideración. Si la seguridad eran importantes para usted, entonces sería su arquitectura sea flexible a las personalizaciones menores de comunicación entre el servidor y la aplicación de parches frecuentes. La mayoría de los sitios web, incluso grandes empresas legítimas, nunca se fijan sus agujeros de seguridad, incluso si se ven comprometidos. Debe estar continuamente fijación de agujeros de seguridad y cambiar las cosas para evitar agujeros de surgir si se desea evitar ser comprometida en el primer lugar.

Para evitar convertirse en un distribuidor de software malicioso que sugeriría hacer reglas duras y rápidas sobre cómo se sirve de medios que contenga cualquier tipo de script del lado del cliente. secuencias de comandos del lado del cliente se puede encontrar en JavaScript, ActiveX, Flash, Acrobat, Silverlight y otro código o plugin que se ejecuta en el sistema cliente. Políticas para servir contenido que deben existir para que anómala fragmentos de código se pueden identificar de inmediato. Mi recomendación es que nunca código de inserción del lado del cliente directamente en un navegador, pero siempre referencia a algún archivo externo. También sugeriría conslidating como medios de mente para darle un mejor control de activos y ahorrará ancho de banda, tales como servir un gran archivo JavaScript en lugar de 8 pequeños. También recomendaría obligando a estos medios de comunicación en un sistema de distribución de contenido externo que hace referencia a su dominio en su estructura de directorios. Que los medios de manera que no se sirve de sus servidores directamente y si sirve directamente de usted puede identificar rápidamente como potencialmente malicioso y necessittating una revisión de seguridad.