DMZ Plus
You set up a dmz plus zone by placing public servers in a segmented network with strict firewall and identity checks. This design adds user identity rules on top of classic perimeter subnets to block lateral movement. Teams often build this layout to isolate web traffic from private databases. Still, broad internal roles still let logged-in users run risky queries once they pass the boundary. How a dmz plus architecture works in practice A classic perimeter subnet sits between the public web
Plus: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a dmz plus zone by placing public servers in a segmented network with strict firewall and identity checks. This design adds user identity rules on top of classic perimeter subnets to block lateral movement. Teams often build this layout to isolate web traffic from private databases. Still, broad internal roles still let logged-in users run risky queries once they pass the boundary.
How a dmz plus architecture works in practice
A classic perimeter subnet sits between the public web and your private internal network. Outer firewalls let public traffic reach web nodes inside that middle zone. Inner firewalls block public traffic from moving straight into your private database subnets. A dmz plus setup improves this old model by adding identity checks and stricter routing rules.
First, the network team splits the middle zone into smaller segments for each app. One app cannot talk to another app in the same zone by default. Next, admins link network rules to user roles from a central identity tool. An engineer must log in and pass multi-factor checks before opening a network path.
Once the network check passes, the user logs into the target server or database. The server checks its local role list to see what that user can do. If the local role allows write commands, the user can change data right away. All network packets flow through the open port until the user logs out.
What network zones solve and what they miss
This segmented layout stops outside bots from scanning your private database servers. If an attacker compromises a public web node, the inner firewall blocks network scans. Splitting apps into small subnets also stops worms from jumping across every server in the zone. Network logs show which IP address opened a port and when that link closed.
Yet network boundaries only decide who can reach a port and log in. They do not inspect what individual commands, queries, or requests do in flight. Once an engineer opens a valid database session, the firewall sees only encrypted packets on an allowed port. The network rule cannot tell the difference between a safe read query and a table drop.
Plus: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Teams also hand out shared admin roles inside the private zone to speed up daily fixes. When five engineers share one strong role, audit logs cannot tie a bad command to one person. If a query pulls customer emails, phone numbers, or card numbers, the firewall sends the raw text back. Network rules alone cannot rewrite sensitive fields in results or pause a risky command for review.
Steps to tighten permissions inside segmented zones
Start by auditing every firewall rule that points from the middle zone into private subnets. Remove broad subnet rules and allow only specific server IPs and ports. Next, replace shared server accounts with individual roles tied to your identity provider. Give each role the minimum read or write rights needed for daily work.
Even with clean network rules, teams still need visibility at the command level. You must see every query and script run inside the private zone. You also need a way to mask card numbers and national IDs in query results.
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
How does a dmz plus differ from a standard perimeter subnet?
A standard subnet uses only IP addresses and port rules to filter traffic. The upgraded model adds micro-segmentation and ties network paths to verified user identities.
Do inner firewalls stop engineers from running bad SQL queries?
No, inner firewalls only check if traffic can cross a network port. Once a session starts, the firewall cannot read or block specific database statements.
How can teams protect sensitive data crossing network zones?
Teams should inspect traffic at the command level rather than the packet level. Data masking rules can then rewrite emails, phone numbers, and card numbers in query results.