Goodby VPN
You say goodby vpn by moving from shared network tunnels to strict user identity checks. Instead of putting laptops on the private network, you verify each person before they log in. Teams often start by linking cloud roles and firewall rules to their identity provider. Still, broad network permissions still let users run any command once they log in. How a goodby vpn setup works in practice A classic virtual private network places a user device right inside your private subnet. Once the tunn
VPN Access Control: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You say goodby vpn by moving from shared network tunnels to strict user identity checks. Instead of putting laptops on the private network, you verify each person before they log in. Teams often start by linking cloud roles and firewall rules to their identity provider. Still, broad network permissions still let users run any command once they log in.
How a goodby vpn setup works in practice
A classic virtual private network places a user device right inside your private subnet. Once the tunnel is open, the network trusts traffic coming from that device IP. Moving away from a tunnel changes how you set up permissions for your team. You stop routing whole subnets to user laptops over a virtual network interface.
Instead, you set up each server, database, and internal app to check user identity. First, the engineer logs in to a central identity provider using multi-factor checks. The identity provider checks the user group and device status against your security rules. Next, the cloud provider maps that group to a native role with specific permissions.
You also update firewall rules so servers reject broad traffic from shared address pools. Each service only accepts requests that carry a valid user identity and role match. Admins group engineers by job duty and assign read or write roles per service. When someone leaves the team, removing their central account stops their sessions right away.
What native network and role changes leave open
Retiring the network tunnel solves the big problem of lateral movement across your subnets. An attacker who gets onto one laptop can no longer scan every internal port. Native cloud roles also make it easier to see which person opened a session. You get a clear log of who logged in and when they did it.
Still, native role checks stop working the moment the session starts. A role decides who can log in to a database or a production server. It does not check what individual queries, commands, or requests do in flight. An engineer with a write role can still drop a table by mistake.
Native roles also cannot tell if a read query pulls back a million rows. If a table holds emails, phone numbers, or card numbers, the query returns everything. You still have to share or manage database keys and server roles across teams. Without command-level checks and data masking, removing the tunnel only fixes half the problem.
VPN Access Control: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
How to plan the move away from tunnels
Start by listing every database, server, and internal tool that sits behind your tunnel. Check which teams actually use these systems during their normal weekly work. Often, you will find old test servers that nobody needs to reach anymore. Shutting down unused services reduces the work needed for your migration.
Next, group your remaining systems by risk and data sensitivity. Move low-risk test systems off the tunnel first so teams can test the workflow. Check your logs to make sure every login ties back to a single person. Once the test flow works well, move production databases and servers over in phases.
Finally, add controls for what happens inside the session after a user logs in. Look at how you review risky commands and how you handle sensitive data columns. Masking rules that rewrite national IDs or card numbers in results keep data safe. Combining identity checks with live session rules lets you turn off the old tunnel.
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
Why do engineering teams want to replace their VPN?
Virtual private networks give users broad network reach once they log in. If an attacker steals one laptop key, they can reach many internal servers. Replacing the tunnel limits each person to the specific tools they need for work.
Do cloud identity roles replace all VPN functions?
Cloud roles verify who can log in to a server or a database. Still, they do not inspect the commands or queries a user runs after login. Teams still need a way to review risky actions and mask sensitive data fields.
How can we protect sensitive data after removing the network tunnel?
You can add data masking that rewrites matched fields in query results. This approach replaces emails, phone numbers, and card numbers before results reach the user. Engineers can still fix bugs and run checks without pulling raw private data.