DMZ and Non DMZ
To separate dmz and non dmz networks, place public servers in a perimeter subnet. Then put private databases behind a second internal firewall. Network teams build these two zones to keep outside web traffic away from core data. Still, broad firewall rules or shared login keys often bridge this gap. When a team grants wide network routes, one bad login exposes private systems. How dmz and non dmz network architecture works A perimeter network, or DMZ, sits between the public internet and your
Non-Human Identity Management: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To separate dmz and non dmz networks, place public servers in a perimeter subnet. Then put private databases behind a second internal firewall. Network teams build these two zones to keep outside web traffic away from core data. Still, broad firewall rules or shared login keys often bridge this gap. When a team grants wide network routes, one bad login exposes private systems.
How dmz and non dmz network architecture works
A perimeter network, or DMZ, sits between the public internet and your internal network. It holds web servers, mail relays, and public API endpoints. Outside users can reach the perimeter zone to load web pages or send data. They cannot send packets straight to the internal network.
The non-DMZ zone is your private internal network. It holds databases, internal apps, and core services that store sensitive records. No public traffic can enter this internal zone directly from the outside internet. Instead, traffic must stop at the perimeter zone first.
Network engineers use two firewalls to enforce this split. The first firewall sits at the edge and filters traffic from the public internet. It only lets approved web traffic reach the public servers in the perimeter subnet. The second firewall sits between the perimeter subnet and the private internal zone. This inner firewall only allows specific servers in the perimeter to talk to internal databases. It blocks all other inbound requests.
In cloud networks, teams build this same split with public and private subnets. Public subnets use an internet routing table so web servers can talk to users. Private subnets use internal routing tables and block direct outside traffic. Security groups and network lists act as the inner and outer firewalls.
Where network zones fall short for engineer workflows
Splitting your network into two zones stops direct network scans from the public internet. It forces outside web traffic to pass through hardened web servers first. This setup works well for automated app traffic that follows fixed port rules.
Still, engineers and support teams still need to reach private servers inside the non-DMZ. They need to run database queries, check logs, and fix broken services. To let humans in, teams open VPN tunnels or forward ports through perimeter hosts. Once an engineer connects to the private subnet, the firewall job is done.
Non-Human Identity Management: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Network firewalls only check IP addresses and port numbers when a session starts. They do not read the SQL queries or shell commands inside that session. If an engineer logs into an internal database with an admin role, everything is open. They can drop tables or read raw customer emails, phone numbers, and card numbers. A compromised laptop on the VPN gets that same open path into the private zone.
How to tighten rules between public and private zones
First, audit every firewall rule between the perimeter subnet and the private zone. Remove broad subnet rules that allow all ports between the two zones. Only allow the exact IP address and port that the public app needs.
Second, stop storing long-lived database keys on servers inside the perimeter zone. If an attacker breaks into a public web server, they look for config files first. Plaintext keys on a public server give attackers an easy path to internal data.
Third, separate human engineer sessions from app traffic. Do not let engineers route through public web servers to reach private databases. Require identity checks and command controls for every human action inside the private zone. Pair network zones with data masking to rewrite emails and card numbers in query results.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits inline in the protocol beside the service as an open-source proxy, a sidecar for your database or API. On every production query an agent or human runs, hoop.dev decides whether to pass, mask, block, or escalate it for review.
Before a query runs, hoop.dev guardrails check the statement against your rules, an AI Analyzer you configure can score intent or hold risky calls for human approval, and hoop.dev data masking rewrites sensitive fields in responses in memory. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the main difference between a DMZ and a non-DMZ?
A DMZ is a buffer subnet that hosts public services like web servers. A non-DMZ is a private internal network that holds sensitive databases and core apps. Firewalls block outside users from reaching the non-DMZ directly.
Should a database ever live in the DMZ subnet?
No, databases that hold sensitive data belong in the private non-DMZ network. Web servers in the DMZ should talk to the private database across an internal firewall. This keeps raw data away from public internet traffic.
Do cloud networks still need DMZ and non-DMZ zones?
Yes, cloud networks use public and private subnets to achieve this exact split. Load balancers sit in the public subnet, while apps and databases stay in private subnets. Network rules alone still cannot inspect what queries a user runs after they log in.