Sps VPN
You set up an sps vpn by linking a local client to a central concentrator. This encrypted tunnel lets remote staff reach private internal networks from outside the office. Most IT teams pair this tunnel with directory groups and basic firewall rules. Still, broad network permissions often give users reach to every server on a subnet. Once inside the perimeter, a single stolen account can put many backend systems at risk. How an sps vpn architecture works A standard virtual private network cre
VPN Access Control: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up an sps vpn by linking a local client to a central concentrator. This encrypted tunnel lets remote staff reach private internal networks from outside the office. Most IT teams pair this tunnel with directory groups and basic firewall rules. Still, broad network permissions often give users reach to every server on a subnet. Once inside the perimeter, a single stolen account can put many backend systems at risk.
How an sps vpn architecture works
A standard virtual private network creates a secure path across the public internet. First, the user starts a desktop client and enters their login details. Next, the central server checks these details against an identity provider and a second factor. When the check passes, the server hands a virtual IP address to the client device.
From that point on, the client wraps network packets in encryption before sending them. The central server unwraps the packets and forwards them to the private subnet. Teams often split traffic by role so contractors and engineers land on different network zones. Admins also decide whether to route all internet traffic or only private subnet traffic. This network layout keeps private servers off the public internet while allowing remote work.
What network tunnels solve and what they miss
A network tunnel does a great job of hiding private ports from public scanners. It also stops attackers on public Wi-Fi from reading traffic between the laptop and office. For years, this perimeter model was the main way teams protected internal tools and databases.
Still, a network tunnel only checks who can join the subnet at login time. It operates at the network layer and knows nothing about database queries or shell commands. Once a user connects to the subnet, they still need separate database passwords or keys. Teams often share these static passwords across whole groups to save time during incidents.
Shared accounts make it impossible to tell which person ran a bad command. Also, the tunnel cannot inspect a query to see what data it returns. If an engineer queries a table, raw emails, phone numbers, and card numbers flow back. A network firewall sees encrypted bytes on a port, not the rows inside the result. To control real actions, teams must inspect commands and data at the resource level.
VPN Access Control: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Steps to tighten remote network setups
Start by shrinking the subnets that each user group can reach after they log in. Replace one flat network zone with smaller zones tied to specific job roles. Next, require multi-factor checks on every login, not just the first login of the week. Shorten session timeouts so idle tunnels close on their own when work ends.
You should also remove shared database accounts and give every service its own distinct role. When users need to run production changes, check the exact command instead of opening ports. Masking sensitive fields like national IDs in query results also reduces data exposure on laptops. Combining narrow network rules with command-level checks closes the gap left by basic tunnels.
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
What is the main risk of a traditional network tunnel?
A traditional tunnel grants broad network reach once a user logs in. It cannot see or limit the exact database queries or shell commands someone runs next.
Does a VPN stop data leaks from production databases?
No, the tunnel only encrypts traffic while it moves between the laptop and the network. Authorized users can still pull raw emails, phone numbers, or card numbers onto their machines.
How can teams reduce lateral movement on internal subnets?
Teams can restrict routes to single ports and pair them with strict role rules. Checking every command and query in flight also stops broad lateral movement across servers.