ZTNA Architecture
You build a ztna architecture by checking user identity and device posture before every session. Instead of opening the whole network, you grant permission to one specific resource at a time. Most teams start this setup by replacing legacy VPN tunnels with identity checks. They link their directory provider to a central control plane that checks device health. Still, teams often copy old, broad group roles into the new system to move fast. When roles stay too wide, a user who logs in can still
Zero Trust Architecture: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You build a ztna architecture by checking user identity and device posture before every session. Instead of opening the whole network, you grant permission to one specific resource at a time.
Most teams start this setup by replacing legacy VPN tunnels with identity checks. They link their directory provider to a central control plane that checks device health. Still, teams often copy old, broad group roles into the new system to move fast. When roles stay too wide, a user who logs in can still run risky commands.
How a native ztna architecture works
A standard ztna architecture separates the control plane from the data plane. The control plane checks who the user is and what device they use. The data plane moves the actual traffic only after the control plane approves the request.
First, the user signs in through an identity provider using multi-factor prompts. At the same time, an agent or browser check reads the device state. It looks at the operating system, patch level, and local security software.
Next, the control plane reads the team rules for that specific app or database. If the user role and device pass the check, the system sets up an encrypted tunnel. The private app never exposes an open port to the public internet. Instead, an inside connector dials out to link the user to that single service. Other machines on the same local subnet stay dark and unreachable.
What network rules solve and what they miss
This network model solves the problem of broad lateral movement across a private subnet. Attackers cannot scan neighboring servers because the network path only reaches one named resource. It also hides internal IP addresses from public scans and drops unmanaged laptops before login.
Still, a network-level check stops looking once the encrypted tunnel opens. It decides who can reach the database port, not what queries they run inside it. Once an engineer connects to a production database, they often share a broad database role. That role lets them read full tables or drop data without a second check.
Zero Trust Architecture: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
The network tunnel also cannot tell safe queries apart from bulk exports of sensitive rows. If a table holds emails, phone numbers, card numbers, or national IDs, the tunnel sends them unchanged. Standard network logs only show that a user sent bytes to a port for twenty minutes. They do not record the exact SQL statements or shell commands that ran during that session. To close that gap, teams need controls that inspect and filter individual commands in flight.
How to plan your rollout without breaking workflows
Start by listing the internal databases, servers, and admin tools your engineers use each day. Group these resources by how sensitive their data is rather than where they sit on the network. Map out which specific job duties require read actions versus write actions on each target.
Put your identity provider and device checks in front of one non-production tool first. Watch how engineers log in and fix any slow login prompts before touching production. Once the login path works well, add command-level rules and data masking for sensitive fields. This approach shrinks your risk step by step while keeping daily work moving.
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 sits inline in the protocol beside each supported service as an open-source proxy, a sidecar for your database or API. For every query or command an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human approval.
First, hoop.dev guardrails block banned queries before they run or hold risky ones for review, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
How is ztna architecture different from a standard VPN?
A standard VPN puts the user device on the whole private network after login. This architecture only connects the user to one approved app or service after checking identity and device state.
Do engineers need an agent on their laptops for this setup?
Some setups require a local device agent to check operating system health and manage tunnels. Other setups work through a browser or standard command-line client without installing a full network agent.
Why do we still need database controls if we have network rules?
Network rules only check if a user may open a session to a database port. Database-level controls check the actual queries in flight and rewrite fields like emails or card numbers in results.