Home / server / Questions / 1167586
Accepted
Shahzad
Asked: 2024-11-09 20:02:30 +0800 CST

Ideal system architecture for sensitive data access through DMZ

  • 772

I'm trying to figure out the best approach for handling external requests. I am working on a system where the application is currently sitting outside (DMZ) and the DB is inside. The specific port required for DB access has been opened from DMZ machine to DB machine.

After discussing with my team, we have agreed that DMZ shouldn't be connecting to the DB directly. After further discussion, we have shortlisted the following two approaches as possible solutions.

To me, both seem to be the same as far as security is concerned since we have the same communication protocols being used and the same number of layers.

Is my understanding correct? If so, would B be the more logical option? A would mean that we have a custom data access service which handles requests from the APP and reads/writes data.

Finally, if we do go with B, would it be recommended that we still use the Data Access Service but it would be internal (i.e. APP -> Data Access Service -> DB)

System Diagram

reverse-proxy

2 Answers

  1. Best Answer

    Whether the App sits behind a reverse proxy or directly in the DMZ, it probably has some vulnerabilities. The extra Data Access Service wraps the database communication and limits it to certain structured API calls rather than allowing raw database queries. Therefore, it protects the database from vulnerabilities in the App.

    • 1

  2. I will not say never make an IP connection to a DBMS in a different firewall zone, but it is difficult to do properly.

    DBMS are not typically exposed to public traffic via IP networking, because they have not been hardened for such a purpose. Their on the wire protocol should be well defined, using encryption, strong authentication and access control. But in practice it is way too easy to set up something weak that should not be on the internet.

    Contrast to for example ssh, an internet standard designed for insecure networks and used in practice in billions of hosts on the internet.

    Or http. http verbs also map well to generic things, so http APIs are everywhere, including in your proposed application architecture. Conveniently, well known http servers have been hardened after years of being publicly facing for web page service. As proxies they are well suited as a production-quality front end tier.

    While either of your ideas move the DBMS traffic to a different firewall zone, it also matters how mature the front end, user facing software is. Parsing arbitrary input, like application requests out of network traffic, is very difficult to do securely. Consider a proxy in front of the application in either case. A good general purpose proxy is a battle hardened transport, a known quantity in security and load balancing.

    An even better network design might do a little more segmentation and a little less trust. Isolate the middle application tier further from the DBMS. There is no reason why the app would for example get a shell to the DB, so deny ssh and other unused protocols with firewall rules.

    • 0