Active Plus VPN
You set up an active plus vpn by linking user groups to network routes. Then you assign IP pools and firewall rules to control private server traffic. Many engineering teams use this method to bring remote laptops onto the private network. Still, broad network rules often let logged-in users reach every internal server and database. When one laptop gets compromised, attackers can move across the whole private subnet. How an active plus vpn routes private traffic A virtual private network buil
Active Directory + VPN Access Control: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up an active plus vpn by linking user groups to network routes. Then you assign IP pools and firewall rules to control private server traffic. Many engineering teams use this method to bring remote laptops onto the private network. Still, broad network rules often let logged-in users reach every internal server and database. When one laptop gets compromised, attackers can move across the whole private subnet.
How an active plus vpn routes private traffic
A virtual private network builds an encrypted tunnel between a user device and your network. The user starts by opening a client app on their work laptop. They log in with their directory username, password, and a second factor code. Once the check passes, the server assigns a private IP address to the laptop.
Traffic for internal servers now travels through this encrypted network tunnel. The network firewall checks the source IP address against a list of rules. Teams often group users by job role, such as developers or support staff. Each group gets a set of network routes that point to specific subnets.
Admins can also set split tunnel rules to manage bandwidth and speed. Split routing sends private work traffic into the tunnel while public traffic goes direct. Full tunnel routing sends every single packet through the company network for inspection. Both options rely on network addresses and ports to make routing decisions.
Why network tunnels leave a gap in database and server control
Network tunnels are great at hiding private ports from the public internet. They stop outside attackers from scanning your internal databases and admin panels. They also protect data in transit when staff work from public wireless networks. For basic network isolation, a virtual private network does its job well.
The big problem starts right after a user connects to the private subnet. The network tunnel only decides who can open a socket to a host. It has no idea what commands or queries run inside that open connection. A developer who reaches a database port still needs a local database password.
Active Directory + VPN Access Control: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Teams often share these database logins or give out broad admin roles. Network logs only show that an IP address talked to a server port. They do not record which SQL query ran or which shell command executed. If a developer runs a bad delete statement, the network firewall cannot stop it.
Moving from broad subnet rules to command level checks
Modern security teams want tighter control over what happens inside a live session. Instead of opening whole subnets, they focus on the exact task at hand. Engineers need to run a specific query or check a single server log. They do not need full network reach across fifty different internal hosts.
Closing this gap means checking every single query and command before it runs. Security rules should look at user identity and the exact action requested. Teams also need a clear log of every statement run against production data. Sensitive fields like emails, phone numbers, and card numbers should get masked in results. This approach shrinks the blast radius while letting engineers fix bugs fast.
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
What does a virtual private network actually protect?
It encrypts traffic between a remote device and your private company network. This stops outsiders on public networks from reading data packets or scanning internal ports.
Why is a network tunnel not enough for database security?
A network tunnel only checks if an IP address can reach a database port. It cannot read SQL queries, block dangerous commands, or mask emails and card numbers.
How can teams reduce risk when engineers work remotely?
Teams should stop sharing static database keys and stop opening broad network subnets. Instead, they should tie every command to a single user identity and log all actions.