Our security experts, database administrators, network team and infrastructure team are all saying it's OK to have the database server located in the DMZ along with the HTTP server and middle-ware server.

Their reason:

If the database server is compromised (because of an insecure middle tier), at least the database server is outside the internal system. If it is inside our network, the hacker can then use the database server to access other systems.

What they are saying is:

  1. Let's not put the middle-ware server behind a second firewall and the database server behind a third firewall.
  2. Let's use just one firewall (the HTTP server's) in case a hacker wants to get our database's sensitive data, at least that's all they can get.

The second statement was actually said... verbatim.

Please note that this database server will hold sensitive information, including bank details.

Now, are these experts making any sense to you? I'm a software developer, and I can't get their logic. It's like, "Put the jewelry box outside the house so that robbers won't bother getting in for the TV?"

  • 50
    my conclusion - these people are not experts in security
    – Rory Alsop
    Commented Nov 27, 2014 at 12:12
  • 3
    But you don't have to have a single DMZ. You can have several rings of trust.
    – Sobrique
    Commented Nov 27, 2014 at 18:55
  • 3
    If the web server got compromised, what good would a firewall do for you? You would have to allow the web server to connect to the database, and it would also have the credentials to do so. Any data the web server is allowed to access in the data base could be accessed by an attacker who compromised the web server.
    – kasperd
    Commented Nov 27, 2014 at 21:46
  • 3
    This question provides no context whatsoever to evaluate the situation properly. What is the new system about, what kind of data is in the DMZ, what are your threat model? There are many factors that needs to be considered to evaluate whether putting DB in the existing secured zone is sensible, or whether you need a new secured zone, or whether putting it outside in the DMZ is sensible. Lacking context, there are only uninformed answers below making generalized statements.
    – Lie Ryan
    Commented Nov 28, 2014 at 0:28
  • 1
    I have the same question as kasperd above. Once your web server is compromised, why does it matter how many firewalls your database server is behind? Clearly the web server must a) have access to the database server through the firewalls to perform queries (even if it has to do queries through the middleware) and b) those credentials are stored in the web server. Assuming your DB only holds data your webserver can access, no matter how many firewalls you place, once your webserver is compromised, you're out of luck, the attacker can slurp everything out of the database.
    – mpontes
    Commented Nov 28, 2014 at 13:27

8 Answers 8


SANS' "Making Your Network Safe for Databases" (http://www.sans.org/reading-room/whitepapers/application/making-network-safe-databases-24) reads a little dated in some sections, but provides a decent "for dummies" level of guidance in the direction you're after.

You could also exhaust yourself poking through the US NIST's resource centre (http://csrc.nist.gov/). I think ISO's ISO/IEC 27033-2:2012 would be on topic too, but don't have a copy at hand to be sure.

You're trying to separate/isolate the most sensitive servers (the database servers) from the most exposed (and therefore vulnerable).

You're proposing a "defense in depth" approach, that seeks to a) prevent attacks where possible, and b) delay their progress (and access to the important stuff) when not.

Ideally, everything is always hardened and patched, servers only listen for traffic on required ports, and only from allowed devices, all traffic "in flight" is inaccessible to unauthorized listeners (through encryption and/or isolation), and everything is monitored for intrusion and integrity.

If all that is in place with 100% certainty, then great, your "opposition" have addressed point a) above, as much as is possible. Great start, but what about point b)?

If a web server does get compromised, your proposed architecture is in a much better spot. Their potential attack footprint, and vector, is much larger than it needs to be.

The justification for separate database from web servers is no different than the justification they've accepted for separating web servers from LAN. More bluntly: if they're so convinced a compromised web server presents no danger to other systems in the same security zone, why do they think a DMZ is required at all?

It's awfully frustrating to be in your situation. At the very least, in your position I'd create a risk memo outlining your concerns and suggestions, and ensure they acknowledge it. CYA, anyway.

  • Thanks everyone for your answers. I wish I could accept all answers but this one was what I directly used to explain the pros and cons of using a 3 tier network security architecture. I was able to convince one of the young member of the security team by giving a summary of all your answers with this as the main point. He eventually explained to the other teams why it should be done.
    – bruce bana
    Commented Nov 28, 2014 at 10:52
  • 1
    For more information on this topic in the future (in case you need more ammo) the term is "N Tiered Architecture". (for google searches)
    – k1DBLITZ
    Commented Nov 28, 2014 at 23:44
  • I posted a comment on the question, but the reality is: What kind of database server is this? What is the application? What is the true risk of a complete data compromise? Commented Nov 30, 2014 at 5:58

It's like, "Put the jewelry box outside the house so that robbers won't bother getting in for the TV?"

Yes, it is exactly like that.

If you don't care about the value of the database, relatively speaking, then sure it makes sense to leave it outside - if the assumption is that the application is horridly insecure, but you need to put it up anyway for whatever reason, and don't want to secure it, then this is makes sense as a way to isolate this horrible insecure system from all the other internal systems.

On the other hand, there really is no excuse to expect to have SUCH an insecure application that allows complete database server takeover. Also there is no real reason to use "exposure" as an alternative to "isolation" - there are simple solutions to do that right too.

When it comes down to it, it sounds like this is one of 2 possible situations:

  1. These so-called "experts" are really clueless.
  2. There are other business requirements that are being traded off here.

I think your analogy works perfectly. If they then tell you the equivalent of "Actually, those jewelries are fake, oh and btw the TV is really a 60" 5K custom job with gold rims", then that might be a sensible tradeoff (still better to do it right, though).
Otherwise, it's likely that there is no way to explain it, since they are working from a lack of knowledge.

  • 1
    Problem is I'm part of the team that is developing the web application. If information is leaked, it's quite easy to point at the application as the culprit when everything is in the DMZ. We're talking about billions of dollars here... not just petty cash. From my point of view, it's #1. That's why it's frustrating and would really want to kindly educate them without being arrogant. Besides, if port and IP addresses are filtered then the only way to have access to the DB is through DB calls... can someone really use SQL scripts to run a terminal and gain access to other internal systems?
    – bruce bana
    Commented Nov 27, 2014 at 12:10
  • By the way, to give context, the business requires the web application two-factor authentication through password authentication and token key generator... that's how sensitive the data are. So I'm really scratching my head on this one.
    – bruce bana
    Commented Nov 27, 2014 at 13:02
  • 1
    Hmm... perhaps you should adjust your analogy "Leave the jewelry box outside the house so the robbers don't make a mess in the kitchen when they make a sandwich because they got hungry while doing all the robbing."
    – AviD
    Commented Nov 27, 2014 at 13:47
  • 3
    Though in that case the better solution would be to leave out a plate of cookies, but I think at that point the analogy starts breaking down....
    – AviD
    Commented Nov 27, 2014 at 13:48
  • 2
    Nobody really knows how to be lonely until they are surrounded by idiots. sigh
    – bruce bana
    Commented Nov 27, 2014 at 15:18

If the database holds card details, it can be very easily argued that you aren't fulfilling the PCI DSS requirement on appropriate protection.

It also fails the sanity checks on single points of failure, and protecting your core assets.

If the data is worth billions, why would you not spend a few thousand more to add layers of protection? Industry good practice is to have layered security zones.

You could point them at PCI, ISF's Good Practice Guide and many others.

  • 1
    No credit card details so I can't use PCI compliance as a motivating factor. Thanks for pointing out ISF. I'm not aware of this. I only rely on the good practices of my peers from previous projects I had and this current configuration is just making my alarm bells go crazy.
    – bruce bana
    Commented Nov 27, 2014 at 12:31
  • Do you know of any international regulations that requires non-exposure of bank accounts and payment details?
    – bruce bana
    Commented Nov 27, 2014 at 13:45
  • 1
    If you aren't holding Credit Card details, what are you holding? Account information? Patient visit information? blueprints for American Made UFOs? If it's that sensitive, maybe you should aim for that level of security or similar levels demanded by say Electronic Health Record systems used for Patient info. No CC info there, but you be screwed sideways if you lose THAT database....
    – WernerCD
    Commented Nov 27, 2014 at 16:32
  • I don't think storing CC details in the db is a problem as long as they are encrypted and keys are away from the DB.
    – AKS
    Commented Nov 27, 2014 at 17:10
  • 3
    @AyeshK - PCI compliance requires payment information to be stored on a secured network. A DMZ would not pass a PCI scan even a little.
    – Logarr
    Commented Nov 27, 2014 at 20:01

If you are suggesting that the database server gets moved from being in the same security zone as the web server to being in the same security zone as some internal systems, then one could reasonably conclude that you are reducing security.

If status quo is that web server and database server are both in the DMZ, and no connections are permitted from DMZ to internal network, then moving the database server from DMZ to internal network would require allowing connections from DMZ to internal network. That would mean you are reducing the security of the internal network without getting significantly better protection for the database.

If you truly believe that the database is more sensitive than the internal network (which may very well be true), then you wouldn't want any compromise of the internal network to get direct access to the database.

So the point you need to make is, that you don't want to move database server from one security zone to another, instead what you want to do is to create an entirely new security zone. To really follow through on that you would actually have to buy an additional firewall and put that between the DMZ and the extra secured network.

Then it boils down to evaluating the cost of buying and maintaining this additional firewall against the additional security it provides.

  • Thanks. That makes sense. Do you know web resources with figures for this setup? I don't think they would be concerned about the cost. However, the additional work they would do to maintain it would prevent them from moving. That's why their brain can only think of "internal network" and "DMZ". They would scatter if they think they have to work.
    – bruce bana
    Commented Nov 27, 2014 at 22:53
  • @brucebana I would just draw the figures on a whiteboard or on a piece of paper. After all the figures would have to take your current network as starting point.
    – kasperd
    Commented Nov 28, 2014 at 7:29
  • @kasperd I'm actually trying to soak up as much info as I can from this brilliant question that was made. And your answer seems to be easy enough to learn (for a 'starter'). Would you mind to draw it on paper or using DIA (dia-installer.de)? That would be awesome of you if you made that drawing. Commented Nov 28, 2014 at 22:11

AvID has already covered the main question, but coming at this from a slightly different angle most firewalls will support multiple interfaces and can provide control of traffic between the interfaces.

Configuring the multiple interfaces to host each of the aspects of the solution (frontend, middleware, backend) would reduce the risk of onward compromise of the database from the web server without necessitating multiple physical firewalls (if that is what the other teams are worried about...is it a cost issue?) and without introducing a route to the internal network.

Just wondering whether this would give you a practical 'lever' to support the argument for implementing some separation i.e. it brings something different to the discussion that they have to counter?

Failing that what about a what-if scenario based on an historic web server vulnerability, which would have resulted in onward compromise of any other server on the same network segment (including the database) and how a layered DMZ would prevent the onward compromise, presumably there would be a monetary cost so it would be 'easy' to illustrate the cost/effort benefit?

  • Good that you also gave practical solutions. My feeling was that if they wanted practical solutions it would be trivial to find one, even for incompetents - I hope that's not the case :-)
    – AviD
    Commented Nov 27, 2014 at 12:05
  • @AviD Very true...just trying to give the OP as much ammunition as possible to 'beat' the incompetents into submission with!
    – R15
    Commented Nov 27, 2014 at 12:09
  • I agree. Cost isn't really an issue. The hardware cost so small compared to the monetary transactions that is saved in the DBs. I sense that it's more of being lazy--don't want to be bothered with configuring and interacting with other teams to setup the secure infrastructure. I wish FUD would work on them but dirty tactics doesn't really suit my personality. I really prefer to have a concrete and very simple way of explaining the pros and cons of this configuration.
    – bruce bana
    Commented Nov 27, 2014 at 12:20
  • Do you know of a resource on network topology with the DB outside the DMZ and also outside the internal network? Giving them the link might work... especially if it has the words "best practice" or "industry standards".
    – bruce bana
    Commented Nov 27, 2014 at 15:17
  • 1
    @brucebana: Create an additional zone (separate LAN or VLAN) with a new IP subnet directly connected to the firewall over a new interface (either physical or statically configured VLAN). There put the database server. --- This is a common practice. Some companies have a very large number of separated zones (almost one zone per server). ------ Of course this brings higher performance requirements on the firewall as the traffic between the application and the database is not being checked in the current design. Commented Nov 27, 2014 at 17:40

Assuming you are attempting to persuade them to do it rather than (necessarily) convince them it is correct:

Explain that when their large customers and prospects come to do a security audit they will fail.

If the obstacle is the business then that will be the only sufficient, and only necessary, reason.

  • 1
    Yes, I am trying to persuade them. I don't care if they take the credit or if they think they came up with the idea--as long as the final topology is secure. Business isn't really the obstacle. Clients don't really have a say on how the organization does its business. The answers I'm getting here also verified my suspicion. I think they would respond to the words "best practice" or "industry standards" and other business-sounding catch phrase.
    – bruce bana
    Commented Nov 27, 2014 at 15:21

One good argument is that the bar really isn't that high to separate the web servers and database servers into separate DMZ's.

Use a real router/firewall, and put the web servers and database servers on separate VLANs, both of them outside the internal secure LAN, with firewall rules controlling access to the bare minimum required ports from the Internet to the web servers, from the web servers to the database servers, and no access at all originating from the web servers to the secure LAN.

The firewall would also prevent any direct access at all from the internet to the database servers, and tightly control any access from the database servers inward to the secure LAN (for authentication purposes or whatever).

That way, the attacker can't even get to the network containing the database servers directly.

If they get a beachhead on one of your web servers, they're still not on the same network with unrestricted access to attack your database server(s), and if you have any kind of log monitoring in place you should receive notifications about the breach of the web servers before the attackers have had much time to attack anything else.

Even if they then manage to breach your database servers after some period of time through the one open port that the web server gets to use to communicate with the database, they've wasted all that time accomplishing relatively little, during which time you have been aware of their attack, instead of spending all of that time getting into your secure LAN.

They can't even reach the LAN from the DMZ where the web servers live, so their only route into the LAN in any form at all is to hop onto the database servers, protected in the other DMZ. Chances are that your database servers are or will be tied into some kind of enterprisey authentication system (Active Directory or whatever). Do you want that capability in the same DMZ with your public web servers?

If I can be concerned enough about security issues to create guest and DMZ subnets at my home, to have a place to put "things" ("Internet of Things") without having them directly on my LAN, a concern worth billions can surely afford the mindshare and time to do the same thing with important web servers and database servers. I'm doing this at the office with a combination of a stack of several-thousand-dollar Procurve managed L2/L3 switches, a SonicWall UTM and a Ubiquiti EdgeMax router. At home, I have a $100 Ubiquiti EdgeRouter Lite, a $100 managed 8-port HP switch and one Ubiquiti Unifi AP that supports multiple VLANs, and my setup is totally capable of doing what we're talking about.

And I get the peace of mind of not worrying that my network-connected DVR, printer, BluRay player, thermostat and whatever else, running who-knows-what buggy out-of-date firmware with who-knows-what undiscovered exploits, might get hacked and reach out to my computer and personal files over the network.

It isn't super hard for security experts to configure this sort of thing, and it certainly doesn't have to involve separate physical hardware for each firewall. SDN (software defined networking) is all the rage these days, right?

Even the $100 EdgeRouter Lite can forward nearly 1 Gbps through the router, with support for multiple virtual interfaces and firewall rules between all of those interfaces.

One tiny box is really a whole basket full of firewalls.

So if you spend real money on a higher-end router, you'll get all those features and a few more with beefier routing performance.

Even something like the Ubiquiti EdgeRouter Pro 8 gives you 2 million packets per second for only $375, with 8 physical interfaces and VLAN subinterfaces on each of those if you need them. If you need higher performance than that, look to Brocade (Vyatta), Cisco, Juniper, etc. for bigger hardware. Or something like Dell/Sonicwall's SuperMassive series. Or run the Vyatta virtual router on a beefy multi-core Xeon server.

I'm not trying to peddle routers, just making the point that the bar isn't actually all that high to get the kind of security separation you should probably have and obviously want here.


Tell your direct manager that you are not authorized to accept that risk on behalf of the company. Point out that the value of the data in the database is $xxx and that that level of risk acceptance must come from someone authorized to do so, and ask him to champion getting a member of executive management to sign-off on the risk acceptance.

To estimate the value of the data, determine whether it is data tied to PCI DSS (if so, look at the cost-per-customer that Target / Home Depot have incurred in lost sales, credit monitoring, fraud), or if it is PII (if so, look at the financial damage per-patient that the medical systems have incurred in lost confidence, identity theft monitoring, lost reputation), or if it is your company's competitive edge (trade secrets, not-yet-released financials, intellectual property) then the value of the data could be the current valuation of the firm.

If you are given a direct order to accept the risk on behalf of the company, you may be asked to begin acting in the capacity of a company officer, and as such, you have an obligation (possibly a legal obligation) to point out that you are a non-appointed person asked to perform as one, and should brief this up the management chain to the company's board of directors. Be prepared for significant blow-back and to expend significant political capital to make this known.

Good luck!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .