Setting up communication between internal database and hosted web server by third party

Question

I am trying to figure out the best and most secure way to do this, if it is possible to do it safe and secure.

Small company. We have a hosted web server from a third party that serves our client web app with bare minimum of data in the database on the server. Want to start offering more features through the portal which would require developing the app to access our more comprehensive data on our internal database. Company doesn't want to put the data on the third party server.

I am thinking one way to do this would be to open the 3rd party server on the database port and only permit traffic from the office IP to that port. On the internal server, open the port for the database only to traffic from the 3rd party server IP.

1) Would this be considered a reasonably safe configuration?

I am neither a network nor security guy, so just gathering information on best practices and getting input on the setup.

I know there can is IP spoofing where an attacker can make their IP look like anyone else's. They'd have to know what IP is exempted beforehand. However, an authentication key between the servers can be setup so even if the IP was spoofed, both ends of the connection would need the key.

2) Would this just be an SSH key?

EDIT 1:

To be perfectly frank, no on at the company is a real understanding regarding security. The don't want our sensitive data on a 3rd party server because they think it is just floating around for anyone in the aether to grab. Basically like googling 'Microsoft', or something, someone can just be like 'my_company data' and get our data. The other reason is practical. The data needs to be immediately available as we are constantly working with it. Having to upload and download from a remote server would be slow and get annoying really quick.

Also, I should add this does involve sensitive information that should not be made public. What it is if a client wants to calculate the 65th percentile for a given item, that request gets sent from the client web app running on the 3rd part server to the internal database where the raw data is to calculate the percentile. The result is sent back to the client web app and presented there. They shouldn't have access to the data directly because it is confidential.

That being said, I was reading about REST API's a little. Some of what I was reading was saying that REST API's may not be the best when sensitive information, or authentication, is required and that SOAP should be used.

Answer 1

Would this be considered a reasonably safe configuration?: No.

The hint here is Company doesn't want to put the data on the third party server. I assume there are good reasons for that. The problem is that if you directly let the web server on the remote host directly access your local database, it just means that the external server gets a direct access to you internal database server.

Database servers are honestly secured, but they are not meant to be direcly under the threat of direct attacks. So when you ask about best practices, this is not one. Definitely.

The correct way would be to build a minimal REST web application in a DMZ inside your internal network. It should be accessible from the external server that will send requests to it, and this relay will has direct access to the internal database. You have to apply standard rules (SSL) to secure the communication between the remote host and the relay, install the minimum on the relay (the more software, the higher risk), and allow as few users as possible to access it.

That way even if an attacker could take control of the remote host, he will still have to pass the local relay before directly being able to attack the database. Ok the requests could already be harmful, but IMHO far less that a direct access.

Answer 2

I think you should segregate these two databases in to two different environment. Both have different kind of data which are in two different privilege levels. do not trust the traffic or data rest in the 3rd party Database. So you should prevent traffic from 3rd Party DB to your own DB.

Perform basic level Harding on your local database by adding firewall etc.. Now you have 3 segregated entities (web server, 3rd party DB and your DB). Next thing is , we need to consider what an attacker can do the data in-transit. They can eavesdrop and perform data alteration. the easiest way you can mitigate this is enable the SSL/TLS in the Database server.

If the attacker gain a Root/Admin access to your Web server, then the situation changes. SSL cannot prevent anything in this situation because the attacker can read your config entries.

Do not leave any config entry in plain text. (connection strings and passwords to the DB). Try to securely store these config values using encryption and secure storage (eg : a keystore if you are using Java in your Web server)