Why VPNs Are the Wrong Shape for Database Workloads
A VPN answers a network question: “Should this laptop behave like it is on the corporate LAN?” A database session answers a data question: “May this human, with this device posture, run these statements against this cluster for this long?” When you conflate the two, you inherit VPN debt—broad east-west reach, stale profiles, contractor laptops treated like trusted inside hosts—while still failing the finer points of least privilege on the wire to port 5432 or 3306.
Attackers love that mismatch. Phished VPN credentials plus a reachable admin port equals interactive looting. Even without drama, operations teams struggle to prove which person issued a destructive DELETE when five teams share the same tunnel and sometimes the same break-glass login. Database access without VPN is therefore not about removing encryption; it is about replacing implicit network membership with explicit, attributable authorization to a single datastore.
Define Success in One Sentence
Your north star: every production query path requires SSO (ideally with MFA), issues short-lived credentials or tokens, lands on a private interface (not a public hostname), and emits structured logs that tie session IDs to a corporate identity and a ticket or incident reference.
Reference Architecture: From Identity to TCP Without a Tunnel
The following pattern is what platform teams implement when they retire VPN-first DB access but still need developers, analysts, and on-call engineers to reach Postgres, MySQL, SQL Server, or managed cloud equivalents.
- 1. Front door — Users authenticate to your IdP; optional device checks reduce stolen-session reuse.
- 2. Policy layer — An access broker or PAM edge evaluates group, time window, approval, and sensitivity labels before any DB TCP is allowed.
- 3. Connectivity — Traffic rides private links, identity-aware proxies, or outbound-only agents—never a database listening on 0.0.0.0.
- 4. Credential shape — Prefer per-session users, IAM database auth, or vault-generated passwords that expire in hours—not one shared
adminstring in Slack. - 5. Observation — Proxy query logs, pg_audit, or cloud audit streams feed the same SIEM you use for SSH and Kubernetes.
Brokered access gives you database access without VPN by enforcing policy before packets reach a private listener—shrinking lateral movement versus flat network trust.
Implementation Checklist for Platform Teams
1. Kill the public listener first
If your RDS, Cloud SQL, or self-managed instance still has a routeable public endpoint “for emergencies,” scanners will find it. Move writers and human sessions to private subnets, security groups that reference the broker security group only, and managed DNS inside the VPC. Emergencies should flow through the same brokered path with an accelerated approval—not a second, unlogged door.
2. Split roles by blast radius
Application runtime users should not be able to truncate history tables. Analysts get read-only roles with column masks where needed. Migrations use a migration principal with DDL but not OS superuser. On-call break-glass is a separate role with aggressive alerting and automatic revocation windows. When access is brokered, these roles can be injected at connection time so laptops never store five different static passwords.
3. Prefer IAM-native or vault-issued credentials
Cloud providers offer IAM database authentication patterns that map IAM identities to DB users—excellent when combined with short STS lifetimes. Where that is not available, integrate a vault that rotates passwords per session and never shows the secret in chat. The operational win is the same: database access without VPN does not become database access without governance because you traded one secret for another static file on disk.
What Auditors (and Incident Response) Ask Next
After you remove VPNs from the critical path, reviewers still expect evidence: who approved elevated access, what IP or device class initiated the session, which queries ran under elevated roles, and how exports were controlled. Build those artifacts into the broker workflow—ticket IDs, change records, or automated policy names—so your quarterly access review is a report, not a archaeology sprint through VPN logs that only prove someone was “on-net.”
| Anti-pattern | Safer replacement |
|---|---|
VPN + shared dbadmin password |
Brokered sessions with per-user attribution and expiring credentials |
| Whitelisting developer home IPs on a public DB | Private connectivity plus broker egress controls |
| Permanent read/write to prod “for debugging” | Time-boxed read-only default; write via ticketed JIT windows |
| Dumping full prod to laptops | Server-side workspaces, masked views, or governed extracts |
Where OnePAM Fits
OnePAM is designed for exactly this class of problem: infrastructure and datastore access that must be fast for engineers yet defensible for security. Instead of shipping a flat network trust zone, you publish resources (this cluster, this port, this role) to authenticated principals, capture the session context, and keep credentials ephemeral. That maps cleanly to database access without VPN initiatives where the goal is to modernize connectivity without reopening data exfiltration paths.
Try brokered database access
Give your team a faster path to Postgres, MySQL, and cloud datastores—without VPN sprawl or shared passwords.
Start Free TrialSummary
- Stop using VPN membership as a stand-in for datastore authorization
- Place databases on private networks with deny-by-default security groups
- Broker human access with SSO, MFA, and JIT roles at session start
- Log sessions with business context so audits and IR are straightforward
- Measure success by reduced standing privilege—not by how many tunnels you maintain
When you treat remote database work as a privileged workflow instead of a network side effect, you get sharper controls, happier developers who stop fighting flaky VPN clients, and a security story that holds up under scrutiny. That is the practical meaning of modern database access without VPN: less implicit trust, more explicit proof at every connection.