Zero Trust Networks
You build zero trust networks by checking user identity and device state on every request. Instead of trusting an internal IP address, the network requires strict checks before any session starts. Teams often start this work by replacing legacy VPNs with strict firewall rules and role checks. They map out which users need to reach specific servers and databases. Still, teams often grant broad database roles just to keep daily work moving. Once a user passes the network check, those wide permiss
Zero Trust Network Access (ZTNA): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You build zero trust networks by checking user identity and device state on every request. Instead of trusting an internal IP address, the network requires strict checks before any session starts.
Teams often start this work by replacing legacy VPNs with strict firewall rules and role checks. They map out which users need to reach specific servers and databases. Still, teams often grant broad database roles just to keep daily work moving. Once a user passes the network check, those wide permissions let them run any command.
How to set up zero trust networks
Setting up zero trust networks starts with a central identity provider and strict network segments. First, you remove default trust from all office networks and cloud subnets. No machine can talk to another machine just because they share a local network. Every user and service must prove who they are before they open a socket.
Next, you link your identity directory to your cloud network rules and database roles. When an engineer tries to reach a database, the system checks their group and device status. It verifies multi-factor login tokens and checks if the laptop meets security rules. Only then does the network allow traffic between the user and the host.
Finally, you split your cloud into small zones for each app or data store. A web app can only reach its own database port, not the whole subnet. Engineers only get network paths to the exact hosts their team owns. This design stops attackers from moving sideways across your cloud if they steal one key.
Where network checks fall short
Native network rules and identity checks solve a huge problem for modern security teams. They stop strangers on the internet from scanning your private ports. They also ensure that only known employees with clean devices can open a session. This blocks many common attacks before a packet ever hits your database server.
Still, network rules only decide who can open a port and log in. They cannot see what happens inside the connection after the session starts. Once an engineer logs into a production database, the network check is finished. The firewall sees encrypted traffic on an allowed port and lets every command pass.
Zero Trust Network Access (ZTNA): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
This leaves a big gap during daily operations and live bug fixes. An engineer with a valid role can still run a wide query or drop a table. They can also pull sensitive data like emails, phone numbers, card numbers, or national IDs. Without query-level checks and data masking that rewrites matched fields in results, the risk stays high.
Adding command and query controls
To close this gap, teams need controls that look past the initial login check. True security requires checking every single SQL statement or shell command in flight. Instead of trusting a whole session for hours, you verify each action as it runs. This shifts control from the network cable to the actual data layer.
When you check commands in flight, you can block dangerous drops or require peer approval. You can also apply masking rules that rewrite emails and card numbers in query output. Engineers still get the fast workflow they need to fix bugs and check app state. At the same time, your team keeps a clear log of every query run.
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
Do zero trust networks replace database roles?
No, network rules only control which users and devices can reach the host port. You still need database roles and command checks to control what queries users can run.
Why is a VPN not enough for zero trust?
A standard VPN puts users inside the private network and trusts all their traffic. If an attacker steals one VPN key, they can scan and attack many internal hosts.
How does data masking fit into zero trust?
Masking applies zero trust rules directly to the data returned by a live query. It rewrites sensitive fields like phone numbers and national IDs in results during the session.