Virtual Private Network Account
You set up a virtual private network account by creating a user profile on your VPN server. Next, you link that profile to your central identity provider and issue a client key. Engineering teams often use one shared group for all developers. This broad setup gives every user full reach across the whole internal subnet. If one laptop is lost, the attacker reaches every database and server on that network. How to set up a virtual private network account First, you connect your VPN server to yo
Virtual Private Database + Cross-Account Access Delegation: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a virtual private network account by creating a user profile on your VPN server. Next, you link that profile to your central identity provider and issue a client key. Engineering teams often use one shared group for all developers. This broad setup gives every user full reach across the whole internal subnet. If one laptop is lost, the attacker reaches every database and server on that network.
How to set up a virtual private network account
First, you connect your VPN server to your team directory or single sign-on tool. This link lets the server check who the user is during login. You do not need to manage separate passwords on the network server itself. When someone leaves the company, disabling their main login also blocks their network account.
Second, you group users by their job role instead of using one flat pool. Backend engineers might need to reach staging databases, while support staff only need internal web apps. You create separate profile groups for each of these teams on the VPN server. Each group gets its own IP address pool and routing table.
Third, you generate client files or certificates for each user device. The user loads this file into their local VPN app and signs in with multi-factor checks. Once the handshake finishes, the server assigns a private IP address from their group pool. Network firewall rules then read that source IP to allow or block traffic to specific ports.
What a virtual private network account solves and where it falls short
A virtual private network account protects data moving over public Wi-Fi and untrusted networks. It wraps all packets in an encrypted tunnel between the laptop and your private network. Outsiders on the same coffee shop network cannot read the traffic or steal session cookies. It also hides your internal servers from the public internet so scanners cannot find them.
Still, a VPN works at the network layer, not at the command or query layer. Once the tunnel is open, the VPN stops checking what the user does inside. It decides which IP addresses and ports a laptop can reach. It does not check which SQL queries or shell commands run over that open port.
Virtual Private Database + Cross-Account Access Delegation: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Developers still need local database passwords or SSH keys stored on their own laptops. If they run a bad drop table query, the VPN tunnel sends it right through. Network logs only show bytes sent to a port, not the exact commands run. Teams also struggle when sensitve fields like emails, phone numbers, or card numbers return in plain text.
Managing day-to-day network account hygiene
To keep accounts safe, you must set short lifetimes for every active network session. Force users to log in again with multi-factor checks at the start of each workday. Never let a laptop stay linked to the production network for weeks without a fresh check. Short session windows limit the damage if a user leaves their laptop unlocked.
You should also review your firewall rules and group memberships every single month. Engineers move between projects often, and old group permissions tend to pile up over time. Remove users from production network groups as soon as their current project wraps up. Keep your routing tables tight so each group only reaches the exact hosts it needs.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
How should we handle shared virtual private network accounts?
Never allow shared accounts among engineers or contractors. Every person must have a unique login tied to their own directory identity so logs show who connected.
Should we use split tunneling for developer accounts?
Yes, split tunneling sends only private subnet traffic through the VPN server. Regular web traffic goes straight out, which reduces load and keeps video calls fast.
What happens when an engineer loses a device with an active VPN key?
You must revoke the client certificate on the VPN server right away and disable their directory login. This drops any open tunnel and blocks new logins from that laptop.