Sdp Gateway
An sdp gateway is a network node that hides internal systems until users verify identity. It drops all traffic by default and opens a path only for approved users. Security teams set up this architecture to replace old virtual private networks. This model stops external scanners from finding open ports on the public web. Still, once a user passes the network check, broad database roles still cause risk. A valid user on an open path can still run bad commands. How an sdp gateway works in practi
RDP Gateway: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
An sdp gateway is a network node that hides internal systems until users verify identity. It drops all traffic by default and opens a path only for approved users. Security teams set up this architecture to replace old virtual private networks. This model stops external scanners from finding open ports on the public web. Still, once a user passes the network check, broad database roles still cause risk. A valid user on an open path can still run bad commands.
How an sdp gateway works in practice
A software defined perimeter splits the control plane from the data plane. The user device first talks to a central controller to prove its identity. The controller checks the user role and the health of the client device. No network traffic reaches the actual server during this first step. After the controller approves the user, it sends a message to the gateway. Both the client and the server use single packet authorization to start the link. The firewall stays dark to every other machine on the internet. The node then opens a direct encrypted tunnel for that specific user device. This setup maps network paths to user identity instead of static IP addresses. When the user logs out, the node closes the network port right away. Teams must also manage client agents on every laptop to make this work.
What native network controls solve and what they miss
This network model solves the problem of exposed ports and broad flat networks. Attackers cannot scan or attack a server that they cannot see online. It also stops lateral movement across the local network after a breach. A user only gets a path to the exact host they need. Yet a network tunnel only decides who can reach a host port. It does not check what happens inside the tunnel after the login step. The user still needs a local password or key to log into the database. Teams often share these database logins to save time during daily work. Shared logins make it impossible to see which person ran a specific query. Also, the network node cannot read SQL statements or shell commands in flight. An engineer with a valid tunnel can still drop a table by mistake. They can also pull large tables full of customer emails and card numbers. Network rules alone cannot rewrite sensitive fields or block one dangerous command.
Managing roles and database keys behind the perimeter
Even with dark ports, engineers still need valid keys for each backend system. Managing these local roles across many servers takes a lot of team time. If a developer leaves the company, admins must rotate shared database passwords fast. Revoking the network user helps, but local keys often stay active in scripts. Service accounts and build servers also need paths through the network rules. Teams often create broad rules for these automated tools to keep builds running. Over time, these broad network rules start to look like an old VPN. True security requires checking every single command and query at the protocol level. You need to control the actual actions, not just the network packet path.
RDP Gateway: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How does a software defined perimeter differ from a VPN?
A VPN puts the user onto the internal network with broad IP visibility. A perimeter model hides all ports and opens a path to one host.
Does hiding network ports remove the need for database passwords?
No, the network layer only opens the TCP path to the server port. The user or app still needs a database login to run queries.
Can a network tunnel block a destructive SQL query?
No, standard network nodes only route encrypted packets between the client and host. They do not parse database protocols or block specific SQL statements in flight.