Configuración de la comunicación entre la base de datos interna y el servidor web alojado por un tercero

0

Estoy tratando de encontrar la mejor y más segura manera de hacerlo, si es posible hacerlo de forma segura.

Pequeña empresa. Tenemos un servidor web alojado de un tercero que sirve a nuestra aplicación web de cliente con un mínimo de datos en la base de datos del servidor. Quiere comenzar a ofrecer más funciones a través del portal, lo que requeriría desarrollar la aplicación para acceder a nuestros datos más completos en nuestra base de datos interna. La compañía no quiere poner los datos en el servidor de terceros.

Estoy pensando que una forma de hacerlo sería abrir el servidor de terceros en el puerto de la base de datos y solo permitir el tráfico de la IP de la oficina a ese puerto. En el servidor interno, abra el puerto de la base de datos solo para el tráfico desde la IP del servidor de terceros.

1) ¿Se consideraría esto una configuración razonablemente segura?

No soy un tipo de red ni de seguridad, por lo que solo estoy recopilando información sobre las mejores prácticas y obteniendo información sobre la configuración.

Sé que puede haber falsificación de IP donde un atacante puede hacer que su IP se parezca a la de cualquier otro. Tendrían que saber qué propiedad intelectual está exenta de antemano. Sin embargo, se puede configurar una clave de autenticación entre los servidores, por lo que incluso si la IP fue falsificada, ambos extremos de la conexión necesitarían la clave.

2) ¿Esto solo sería una clave SSH?

EDIT 1:

Para ser perfectamente franco, no en la empresa es un verdadero entendimiento con respecto a la seguridad. No quieren nuestros datos confidenciales en un servidor de terceros porque creen que simplemente está flotando para que cualquiera en el aether lo agarre. Básicamente, como buscar en Google 'Microsoft', o algo así, alguien puede simplemente ser como 'my_company data' y obtener nuestros datos. La otra razón es práctica. Los datos deben estar disponibles de inmediato, ya que estamos trabajando constantemente con ellos. Tener que cargar y descargar desde un servidor remoto sería lento y sería molesto realmente rápido.

Además, debo agregar que esto implica información confidencial que no debe hacerse pública. En qué consiste si un cliente desea calcular el percentil 65 para un elemento determinado, esa solicitud se envía desde la aplicación web del cliente que se ejecuta en el servidor de la tercera parte a la base de datos interna donde los datos sin procesar deben calcular el percentil. El resultado se envía de vuelta a la aplicación web del cliente y se presenta allí. No deberían tener acceso a los datos directamente porque son confidenciales.

Dicho esto, estaba leyendo un poco sobre API REST. Algo de lo que estaba leyendo decía que las API REST pueden no ser las mejores cuando se requiere información confidencial o autenticación y que se debe usar SOAP.

    
pregunta sockpuppet 05.01.2017 - 06:13
fuente

2 respuestas

3

¿Se consideraría esto una configuración razonablemente segura? : No.

La sugerencia aquí es La compañía no quiere poner los datos en el servidor de terceros . Supongo que hay buenas razones para eso. El problema es que si permite que el servidor web en el host remoto acceda directamente a su base de datos local, solo significa que el servidor externo tiene acceso directo a su servidor interno de base de datos.

Los servidores de bases de datos están protegidos de manera honesta, pero no están destinados a estar directamente bajo la amenaza de ataques directos. Entonces, cuando preguntas acerca de las mejores prácticas, esta no es una. Definitivamente.

La forma correcta sería crear una aplicación web REST mínima en una DMZ dentro de su red interna. Debe ser accesible desde el servidor externo que le enviará las solicitudes, y este relé tendrá acceso directo a la base de datos interna. Debe aplicar reglas estándar (SSL) para asegurar la comunicación entre el host remoto y el relé, instalar el mínimo en el relé (cuanto más software, mayor riesgo) y permitir que el menor número de usuarios pueda acceder al mismo.

De esa manera, incluso si un atacante podría tomar el control del host remoto, todavía tendrá que pasar el relevo local antes de poder atacar directamente la base de datos. Ok, las solicitudes ya podrían ser perjudiciales, pero en mi humilde opinión mucho menos que un acceso directo.

    
respondido por el Serge Ballesta 05.01.2017 - 08:56
fuente
0

Creo que debería separar estas dos bases de datos en dos entornos diferentes. Ambos tienen diferentes tipos de datos que se encuentran en dos niveles de privilegios diferentes. No confíe en el tráfico o el resto de datos en la base de datos de terceros. Por lo tanto, debe evitar el tráfico de la base de datos de terceros a su propia base de datos.

Realice Harding de nivel básico en su base de datos local agregando firewall, etc. Ahora tiene 3 entidades segregadas (servidor web, base de datos de terceros y su base de datos). Lo siguiente es que debemos considerar qué puede hacer un atacante con los datos en tránsito. Pueden espiar y realizar alteraciones de datos. la forma más fácil de mitigar esto es habilitar SSL / TLS en el servidor de la base de datos.

Si el atacante obtiene un acceso Root / Admin a su servidor web, entonces la situación cambia. SSL no puede evitar nada en esta situación porque el atacante puede leer sus entradas de configuración.

No deje ninguna entrada de configuración en texto sin formato. (cadenas de conexión y contraseñas a la base de datos). Trate de almacenar de forma segura estos valores de configuración mediante cifrado y almacenamiento seguro (por ejemplo, un almacén de claves si está utilizando Java en su servidor web)

    
respondido por el user3496510 05.01.2017 - 06:55
fuente

Lea otras preguntas en las etiquetas