DMZ Network Design
You build a dmz network design by placing public hosts inside an isolated subnet. Firewalls sit on both sides to filter traffic between the web and private data. Most teams start by setting up perimeter rules that allow inbound web traffic. They then open narrow ports from that middle zone into private database subnets. Still, broad firewall rules and shared keys often let too much traffic pass through. If an attacker takes over a public server, broad rules expose your internal data. How a sta
DevSecOps Pipeline Design: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You build a dmz network design by placing public hosts inside an isolated subnet. Firewalls sit on both sides to filter traffic between the web and private data. Most teams start by setting up perimeter rules that allow inbound web traffic. They then open narrow ports from that middle zone into private database subnets. Still, broad firewall rules and shared keys often let too much traffic pass through. If an attacker takes over a public server, broad rules expose your internal data.
How a standard dmz network design works
A strong perimeter layout separates untrusted public traffic from your private backend systems. Teams choose between a single firewall with three legs or two separate firewalls. In a dual firewall layout, the outer wall faces the open internet directly. It blocks all inbound traffic except requests going to specific public web hosts. Those public hosts live inside the middle buffer zone and handle user requests.
The inner firewall sits between this buffer zone and your private internal network. This inner wall enforces strict rules on which hosts can talk to databases. Only specific hosts in the buffer zone can send requests across this boundary. Network engineers set up routing tables so external packets never reach private subnets directly. Every packet must stop at a host in the middle zone first.
Teams also split the buffer zone into smaller segments for different public apps. Web servers, mail relays, and partner APIs each get their own isolated subnet. Local rules block traffic from moving sideways between these different public hosts. If one public app fails, the other hosts in the zone stay safe.
What perimeter firewalls solve and what they miss
Network segmentation stops outsiders from scanning or hitting your private databases from the web. It forces all traffic through known checkpoints where packet filters check IP addresses. This layout blocks network sweeps and keeps raw database ports off the internet. It gives your team a clear map of how data enters the network.
Still, firewalls only check network addresses and ports when a session first starts. Once a port is open, the firewall cannot read the commands inside the traffic. Engineers also need to log in to hosts in both zones to fix bugs. Teams often open admin ports through the firewalls so staff can run checks. Once an engineer logs in, network rules do not limit what commands run.
DevSecOps Pipeline Design: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
A valid user or a stolen app key can still run destructive queries. The inner firewall sees a trusted IP address and lets the bad command pass. Network logs only show that packets moved between two hosts at a given time. They never show which user ran a query or what records came back. If a query returns customer emails or card numbers, the firewall cannot mask them. Masking rewrites matched fields in results, which requires inspecting traffic above the network layer.
How to tighten traffic across network zones
Start by removing all direct inbound admin ports from the outer firewall rules. Public hosts should only accept web traffic on the exact ports the app needs. Next, check the inner firewall and drop any rule that allows wide subnet ranges. Replace broad subnet rules with rules that name single host addresses and single ports.
Review how apps in the middle zone log in to your internal databases. Remove shared master database keys from config files sitting on public web servers. Give each app a dedicated database role that can only read needed tables. Finally, add controls that check individual queries and commands instead of just IP addresses.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Should a database ever sit inside the DMZ subnet?
No, you should always keep databases inside the private internal network zone. If a public host gets compromised, local database files would be exposed right away. Keep data on the private side and allow only narrow app queries across.
Is a single firewall enough for a small network?
A single firewall with three network ports can work for small setups. Still, a single bug in that firewall rule set can expose the private network. Using two separate firewalls from different vendors reduces the risk of a single flaw.
Why do teams still need controls beyond network segmentation?
Firewalls only control which machines can talk to each other over a port. They do not verify human identity or check the actual database statements inside traffic. You still need statement-level checks and data masking for emails and phone numbers.