Define Network Access
You define network access by setting up firewall rules, private subnets, and user roles. These controls decide which people and machines can reach your servers and databases. Most teams start by putting databases and servers inside a private virtual network. They then set up virtual private networks or firewall lists to let engineers in. When teams make these rules too broad, any user on the network can reach every internal port. A single stolen key or open port then puts every database at risk.
Zero Trust Network Access (ZTNA): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You define network access by setting up firewall rules, private subnets, and user roles. These controls decide which people and machines can reach your servers and databases. Most teams start by putting databases and servers inside a private virtual network. They then set up virtual private networks or firewall lists to let engineers in. When teams make these rules too broad, any user on the network can reach every internal port. A single stolen key or open port then puts every database at risk.
How teams define network access in cloud setups
To define network access well, teams split their cloud network into small, separate zones. Public zones hold load balancers that take in outside web traffic from users. Private zones hold app servers, internal tools, and core data stores. Security groups and network lists sit between these zones to filter traffic.
Each rule checks the source IP address, the target IP address, and the port number. If a packet matches an allow rule, the router forwards it to the target host. If the packet does not match, the firewall drops the traffic right away.
Engineers also need a way to reach these private zones from their laptops. Teams set up private tunnels that link a remote laptop to the cloud network. The user logs in with an identity provider to start the tunnel session. Once the tunnel is up, the laptop gets a private IP address on that network. The firewall then checks that IP address against its port rules.
Why teams pair network rules with identity roles
IP addresses change often when people work from home or travel. Static firewall lists break when an engineer gets a new home IP address. To fix this, teams link network rules to user groups and machine roles. When an engineer logs in, the network tool checks their team group first. It then opens only the subnets and ports assigned to that specific group.
For server-to-server traffic, cloud platforms let teams attach role tags to virtual machines. A database firewall rule can allow traffic only from machines with the right app tag. This setup stops teams from having to update long IP lists after every deploy. It keeps the network map clean as apps scale up and down.
Zero Trust Network Access (ZTNA): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native network controls solve and what they miss
Network rules do a great job of blocking outside attackers from scanning private ports. They stop unapproved machines from even starting a handshake with a database or server. They also limit how far an attacker can move if one server gets compromised. Every team needs these base rules as a first line of defense.
Still, network controls only care about where traffic starts and where it goes. Once a packet passes the firewall check, the network tool steps out of the way. The firewall cannot see what happens inside that open session after login. It cannot tell a safe read query from a command that drops a table.
Also, engineers still need database keys or server keys once the port opens. Teams often share these static passwords across whole groups to save time. Shared keys make it impossible to tell which person ran a bad command. And if a query returns sensitive fields like emails, phone numbers, or card numbers, the network passes them straight through. Native port rules have no way to rewrite matched fields in results in flight.
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 beside the service as an open-source proxy, a sidecar for your database or API.
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 review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the difference between network rules and database roles?
Network rules decide if your machine can reach the database port over the wire. Database roles decide which tables you can read or write after you log in.
Why is a private tunnel not enough for database safety?
A private tunnel only joins your laptop to the internal network subnet. It does not inspect SQL queries, check individual commands, or mask sensitive data fields in results.
How often should teams review their firewall and subnet rules?
Teams should check their firewall rules and open ports at least once every quarter. They should also remove old rules right away whenever they shut down an app.