Network One Zones
You set up network one zones by grouping cloud subnets into separate trust areas. Each area uses strict firewall rules to control traffic between your apps and databases. Most engineering teams start by placing public web servers in an outer zone. They put private databases and internal services in an inner zone. This basic layout stops outside traffic from reaching private data stores directly. Still, teams often open wide port ranges between zones so developers can debug issues. Once a user or
OCI Security Zones: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up network one zones by grouping cloud subnets into separate trust areas. Each area uses strict firewall rules to control traffic between your apps and databases. Most engineering teams start by placing public web servers in an outer zone. They put private databases and internal services in an inner zone. This basic layout stops outside traffic from reaching private data stores directly. Still, teams often open wide port ranges between zones so developers can debug issues. Once a user or service enters an inner zone, broad roles grant too much control.
How network one zones work in practice
A zone acts as a logical boundary around a set of cloud resources. You build these boundaries using virtual networks, subnet tables, and security groups. First, you map out which services need to talk to each other. Public apps sit in the perimeter zone and take requests from the internet. Worker nodes sit in a middle zone and process jobs from those public apps. Core databases sit in the deepest zone with no public routes at all.
Traffic moves between network one zones through strict routing tables and firewall rules. Every packet must match an allow rule based on its source IP and port. If a web server needs customer data, the firewall checks the zone rule first. The rule allows traffic from the app subnet to the database port only. Everything else gets dropped before it reaches the target host. Teams also attach identity roles to each zone so servers can read cloud secrets.
What native network boundaries solve and what they miss
Native zone rules are great at stopping random network scans and outside attacks. They limit the blast radius when a public server takes a hit. An attacker on a web node cannot ping random internal servers across the cloud. The routing table blocks that path by default. This setup satisfies basic compliance checks for network separation.
Yet network boundaries only check where traffic comes from, not what it does. Once a developer or app passes the firewall check, the network steps aside. The database or server trusts the session for as long as it keeps the session active. A single shared role in that zone can run a drop table query. It can also pull raw emails, phone numbers, and card numbers in bulk. Static keys stored inside a trusted zone often stay valid for months. Network logs show that packets flowed between two IP addresses on a specific port. They never show which user ran a risky command or what data came back.
OCI Security Zones: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Why teams need statement-level control inside zones
Relying on IP rules alone forces teams into a hard trade-off. If you lock down every subnet, engineers cannot debug live issues fast. They end up asking ops teams to open temporary firewall holes during outages. Those temporary rules often keeps the session active long after the fix is done. Over time, your clean zone map turns into a messy web of exceptions.
Real security requires checking every action after the network connection is made. Teams need to tie every query and command to a real person. They also need to inspect requests in flight and mask sensitive fields in results. When masking rewrites card numbers or national IDs in results, raw data stays safe. Adding command checks and live data masking closes the gap that firewalls leave behind.
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
What is the main purpose of network one zones?
They split a flat cloud network into smaller, isolated trust areas. This layout stops unauthorized traffic from moving freely between public apps and private data.
Do network zones protect against bad database queries?
No, network zones only filter traffic by IP address and port number. Once a port is open, the zone cannot read or block risky queries.
How should engineers run fixes inside a locked zone?
Engineers should log in with their own identity instead of using shared network keys. Every command should go through an approval flow and leave a clear audit log.