I am quite new to the DMZ concept and working on a project as part of my master thesis where Remote access is required for the Development environment. However, there is a functional requirement for minimum latecy in the connection since video playing slow or getting stuck is not acceptable. So I have this thought of moving DB server from internal network to the DMZ zone. Where all development tools that are running on Server 1 will sit next to Server 2 running the DB.

However there are the following issues that erupt from this:

  1. Data Redundancy
  2. Data is edited by both internal and external employees so the quality and real time access to current data is a must.
  3. And of course the biggest of all is that if DB server is compromised all the data on it will be compromised as well.

So my other thought is to move only the specific instances of the DB required during development process which will sit next to the Server 1 which is running the development tool. Though it doesn't the system fool proof, it reduces the risk of complete Db compromise.

Still, the question remains on maintaining data quality in the DB and the replication of data from the DB server inside the internal network to the DB server running in DMZ.

Can someone please give me any thoughts on this approach??? Considering factors like maintaining consistency of data, cost and performance and ultimately the security.

Thanks a lot in advance.

  • @bethlakshmi thanks for editing... wrote it in quite a rush. :) – sup May 23 '13 at 17:39

Is there any reason you wouldn't just NAT connections from the gateway to the internal DB server rather than completely moving the box to the DMZ?

As for the issues you list, I wouldn't worry too much about #3, because no matter what your DB server needs to be properly secured. The only way to really mitigate that risk is have your development box make calls to an API that handles communication with an internal or otherwise unexposed DB box. That way you don't have to totally open the floodgates to the DB server.

It sounds like you may have other data unrelated to the development tool on this DB server as well, which makes moving it and managing the risk undesirable.

Bleh, making these decisions is never fun, but ultimately that's our jobs, right?

If using NAT to handle the routing isn't sounding too good to you, and setting up API access to the DB isn't feasible either; you've got to take a good hard look at what this DB server is up to and go from there.

The entire purpose of a DMZ is to expose necessary services to the outside world while protecting internal operations as much as possible. Meaning, just because I need DB access doesn't mean I need to be able to ping every machine and printer in the office. That said, if you've got data on that DB server that has no business being accessible from the greater internet then that server absolutely does not belong in the DMZ and you should really setup a new DB server to house that data which does need to be accessed from the greater internet. That's exactly the purpose of the DMZ.

As for the data redundancy bit, I do not believe this situation warrants having two servers with the same data replicating to each other with internal users hitting one and external users hitting another, that's almost always a terrible architecture. If this DB instance ends up in your DMZ you'll have to setup routing and/or use internal DNS to ensure local traffic gets to the box in the DMZ.

Left Field: Rereading your question I'm wondering if there isn't another solution hiding here to get at your real issue which seems to be latency and availability of delivered data... if you've got files that need to be delivered publicly with low latency is there any reason you aren't storing them on some third party storage like s3 or cloudfront CDN?

The approach would essential be storing all the information about the file on the DB, generating some hash for a given file name (you mentioned videos?) and storing a link to S3 or the CDN in the DB. If the only reason you're thinking of moving the DB is to control latency on data blobs that get sent to a user I think you're better off rethinking the problem rather than coming at this as a question of data "access" which is ultimately what the DMZ is all about.

  • First of all thanks for you insight. Now your right for most of the part even I'm reluctant to move whole DB machine to DMZ and so I thought of moving just the required instances to DMZ. Definetly, there is other data on the DB server which has no business to be in DMZ. Thus the idea of moving/replicating required instances to DMZ. Now as to why I thought of moving development tools and DB server together is indeed to handle latency. Because the development tools and the DB servers are not at the same location(physically). – sup Jun 1 '13 at 23:36
  • Because isolating the internal network from the DMZ seems like a good idea to me (security in depth). And so if we look at the scenario where development tools are running in DMZ but for some requirements developers are entering the internal network just to get access to those instances on DB server??? Okay, there are ways to control traffic and to restrict them through ACLs and other checks but in case of successful attack jackpot is hit. But hey, I'm just thinking aloud here may be there are unbreachable ways of routing such traffic. – sup Jun 1 '13 at 23:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.