DMZ in Network Diagram
You draw a dmz in network diagram layouts by placing a buffer subnet between two firewalls. This zone holds public servers while keeping private databases in an inner subnet. Teams often build this layout to separate web traffic from internal systems. When firewall rules or user roles stay too broad, attackers can still reach core data. A wide port rule lets bad traffic move straight into the private zone. How to map a dmz in network diagram layouts A standard diagram starts with the public i
Just-in-Time Access: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You draw a dmz in network diagram layouts by placing a buffer subnet between two firewalls. This zone holds public servers while keeping private databases in an inner subnet. Teams often build this layout to separate web traffic from internal systems. When firewall rules or user roles stay too broad, attackers can still reach core data. A wide port rule lets bad traffic move straight into the private zone.
How to map a dmz in network diagram layouts
A standard diagram starts with the public internet on the far left or top edge. Traffic from outside users hits an outer firewall first. That first firewall blocks all ports except the ones your public apps need. Behind this firewall sits the buffer subnet, which holds web servers, mail servers, and load balancers.
Next, you draw a second firewall between the buffer subnet and your internal network. This inner firewall checks every packet that moves from the public servers to private systems. Your private subnet sits behind this second wall and holds databases, internal apps, and file stores. Some teams use a single firewall with three network ports instead of two separate boxes. In that setup, one port links to the web, one to the buffer zone, and one to the private zone.
Choosing between single and dual firewall designs
A single firewall with three legs costs less money and takes less time to draw. The team manages one set of network rules in one central place. Yet this layout creates a single point of failure for the whole company. One bad rule on that box can expose the private subnet to the public web.
A dual firewall layout splits the boundary across two distinct devices, often from different vendors. The outer device filters wide web traffic and stops basic floods at the edge. The inner device enforces strict rules between the public app servers and internal data stores. Both must fail or have bad rules before an outside user reaches the private zone.
Just-in-Time Access: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What network zones solve and what they miss
Network zones and firewall rules control which machines can open a socket to another host. They stop outside computers from sending direct packets to your private database servers. This layout limits how far an attacker can scan if they breach a public web server.
Still, a network diagram only decides which IP address and port can start a session. Firewalls do not check the individual SQL queries or shell commands that run inside an open session. Once an engineer or an app logs in across the inner firewall, the network allows every command. If an engineer runs a broad delete query, the firewall passes it right through. If a script pulls thousands of customer emails, phone numbers, or card numbers, the subnet rule cannot rewrite those fields. Teams still need a way to inspect each command in flight and mask sensitive fields in results.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Where does the database sit in a DMZ diagram?
The database always sits in the private internal subnet behind the inner firewall. You should never place a primary database inside the public buffer zone.
Which hosts belong inside the buffer subnet?
Place any host that must talk to outside users inside the buffer zone. Common examples include web servers, API hosts, DNS servers, and mail relays.
Do cloud networks still need a DMZ diagram?
Yes, cloud networks use public and private subnets to do the same job. You map public load balancers in an outer subnet and put databases in a private subnet.