Asu VPN
To use an asu vpn, install the campus client and log in with your credentials. The client builds an encrypted tunnel between your remote device and the private campus network. Engineering and research teams use this setup to reach internal servers and databases from home. Still, once a device joins the private network, broad network rules often expose too many internal ports. How an asu vpn works for remote network entry A virtual private network extends a private local network across the pub
VPN Access Control: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To use an asu vpn, install the campus client and log in with your credentials. The client builds an encrypted tunnel between your remote device and the private campus network. Engineering and research teams use this setup to reach internal servers and databases from home. Still, once a device joins the private network, broad network rules often expose too many internal ports.
How an asu vpn works for remote network entry
A virtual private network extends a private local network across the public internet. Users start by installing a dedicated desktop or mobile client on their machine. When the user starts a session, the client asks for a username and password. Most setups also ask for a second factor through a mobile prompt or hardware key.
After the login succeeds, the server assigns a private IP address to the user device. All traffic bound for internal hosts now travels through an encrypted network tunnel. Campus firewalls inspect the source IP address to decide which subnets the user can reach. Some teams split traffic so only internal requests use the tunnel, while public traffic goes direct.
Network admins group users into roles based on their department or research lab. A student role might only reach library tools and shared compute clusters. A staff engineer role might reach production databases, internal code hosts, and cloud subnets. Admins manage these rules by updating firewall tables and directory groups.
Where network tunnels fall short for database and server security
A network tunnel solves one main problem: keeping public internet traffic away from private ports. It hides internal hosts from outside scanners and encrypts data moving across public Wi-Fi. For basic web apps and file shares, this perimeter check works well enough.
The operational gap appears after a user passes the perimeter check and enters the subnet. A network tunnel checks who logs into the subnet, not what commands they run inside. Once a laptop gets a valid network route, it can talk to any open port on that segment.
VPN Access Control: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
To reach an internal database or server, engineers still need separate database passwords or SSH keys. Teams often share these static credentials in chat rooms or store them in local plain-text files. If an attacker steals a laptop with an active tunnel, they can scan the whole subnet. Network logs only show packet counts and IP addresses, not which SQL query ran or which table changed.
Moving from broad network routes to command-level control
Modern engineering teams reduce risk by separating network routing from resource permissions. Instead of granting full subnet routes, admins restrict rules to single apps and specific actions. Every database query or server command should link back to an individual user identity.
Auditors also need clear records of who ran what command and when it happened. Packet logs from a network concentrator cannot answer those questions during a security review. Teams also need a way to mask sensitive fields like emails, phone numbers, and card numbers in query results. Adding command-level checks and data masking closes the gap left by basic network tunnels.
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 runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values 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
Why do I still need database passwords when using an asu vpn?
The network tunnel only gives your computer a route to reach the database server port. You still must log in to the database engine itself with a separate username and password.
Can network admins see which SQL queries I run over the tunnel?
No, standard network logs only record source IP addresses, destination ports, and byte counts. To record exact SQL statements, teams need a tool that inspects database protocol traffic.
What happens if a shared database password leaks on the internal network?
Anyone with an active network tunnel on that subnet can use the leaked password to read data. Also, database logs will only show the shared account name, not which person ran the query.