Software-defined Perimeter
A software defined perimeter hides servers from the public net until users pass checks. It verifies user identity and device state before it opens a direct network tunnel. Teams often set up this model to replace wide virtual private networks. Still, once the tunnel opens, broad server roles still allow dangerous commands or queries. How a software defined perimeter works A software defined perimeter uses three main parts to control network entry. These parts are a client app, a central contr
Software-Defined Perimeter (SDP): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A software defined perimeter hides servers from the public net until users pass checks. It verifies user identity and device state before it opens a direct network tunnel. Teams often set up this model to replace wide virtual private networks. Still, once the tunnel opens, broad server roles still allow dangerous commands or queries.
How a software defined perimeter works
A software defined perimeter uses three main parts to control network entry. These parts are a client app, a central controller, and an accepting host. First, a user logs in through the client app on a laptop. The central controller checks the user identity with the team directory. It also checks the laptop state to see if security rules pass.
Before this check finishes, the accepting hosts drop all network packets. Port scanners on the public net see nothing at all. This method is called a dark cloud model because servers stay dark. Once the controller approves the user, it sends a message to the host. The host then opens a tiny hole for that single user device.
The client app and the host build an encrypted tunnel for traffic. The user only sees the specific servers tied to their team role. Other servers on the same subnet stay dark and out of reach. When the user logs out, the host closes the network path right away.
What network perimeters solve and what they miss
This setup stops lateral movement across a private subnet very well. Attackers cannot scan ports or hop from one web app to a database. It also removes the pain of shared network routes for remote staff. Each user gets a private, one-to-one network path to an approved host.
Yet this model only decides who can reach a host port. Once the tunnel is up, the network tool steps out of the way. The user still logs in to the database or server with local roles. Teams often share broad database accounts to move fast during an outage. If a developer has a wide role, the tunnel allows every query through.
Software-Defined Perimeter (SDP): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
The network tunnel does not read SQL statements or shell commands in flight. A user with a valid tunnel can run a full table dump. That dump can return raw emails, phone numbers, card numbers, or national IDs. A bad query can also drop a table or change live rows. Network tools log packet flow, not the exact commands run inside the session.
Why teams need control inside the session
Passing a network check is only the first step for safe operations. Security teams also need to know what happens after the port opens. Auditors ask for a clear log of every command and query run. A simple log of IP addresses and open ports does not pass audits.
To close this gap, teams must govern actions at the command level. Every query or shell command needs its own check before it runs. Sensitive fields like card numbers or emails need masking in query results. Masking rewrites matched fields in results so raw values do not leak out. Combining network checks with command checks gives teams full control over live data.
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 a software defined perimeter different from a VPN?
A traditional VPN places a user on an entire private network segment. A software defined perimeter opens a single path to one approved host port. Other hosts on the same network remain dark and unreachable to the user.
Does a software defined perimeter replace database roles?
No, it only controls which user devices can reach the database network port. You still need a way to manage database logins, queries, and data masking. Without query controls, any user who passes the network check has full role rights.
Can a software defined perimeter mask sensitive data in queries?
No, because it works at the network transport layer, not the protocol layer. It sends encrypted packets between the laptop and the host without reading queries. To rewrite emails or card numbers in results, you need protocol-level inspection.