Security teams should separate connectivity from authorisation. VPN access may get a user onto the network, but database privilege should be brokered, time-bound, and recorded at the session layer. The practical goal is to eliminate broad reach, prevent raw credential exposure, and ensure every privileged action is tied to a clear identity and approved task.
Why This Matters for Security Teams
VPNs answer the connectivity question, not the privilege question. A user or workload can be on the network and still have no legitimate reason to query a production database, run ad hoc SQL, or export sensitive records. That is why database access should be brokered separately from network access, with approval, time limits, and auditability at the session layer. The risk is not theoretical: NHIs are a primary failure point in modern identity programs, and the Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges.
Teams often keep VPN trust because it is operationally familiar, not because it is secure. Once a session lands inside the network, a compromised endpoint, stolen token, or misused service account can move laterally to databases that were never meant to be broadly reachable. The OWASP Non-Human Identity Top 10 reinforces that identity and secret handling failures are a recurring control gap, especially where static access persists after the original task ends. In practice, many security teams discover excessive database reach only after a credential or tunnel has already been abused, rather than through intentional privilege design.
How It Works in Practice
The practical model is to split access into three layers: network reachability, authentication, and authorisation. VPN may still be used for transport, but it should not imply database trust. Instead, the database connection is brokered through an access gateway or privileged session layer that issues short-lived access for a named purpose, records the session, and revokes access when the task ends. This aligns with current Zero Trust guidance and with identity-first designs described by NHI Management Group in the State of Non-Human Identity Security.
For human operators, that often means just-in-time approval, MFA, and role scoping to a specific database, schema, or read-only function. For automated jobs and agents, the better primitive is workload identity, not shared secrets. Current guidance suggests using cryptographic workload identity such as SPIFFE/SPIRE or OIDC-issued tokens so the database can verify what is connecting, what task it is performing, and how long the credential should live. Session brokers can then inject ephemeral credentials at connection time, avoiding long-lived passwords and reducing the blast radius of compromise.
- Authenticate the caller at the identity layer, not only at the network edge.
- Issue time-bound database credentials per session or per task.
- Bind access to approved purpose, database, schema, and command class.
- Record the full session, including privileged statements and data export activity.
- Revoke access automatically when the job completes or the TTL expires.
Security teams should also enforce policy-as-code so access decisions can incorporate context such as workload identity, ticket reference, environment, and data sensitivity at request time. These controls tend to break down in legacy database clusters that cannot support proxying, command-level logging, or short-lived credential issuance because the platform was built around static accounts and direct network trust.
Common Variations and Edge Cases
Tighter database brokering often increases operational overhead, requiring organisations to balance reduced blast radius against developer friction and incident response complexity. That tradeoff is real, especially where analytics teams need interactive access, legacy applications expect persistent connections, or replication jobs use embedded credentials. Best practice is evolving, but there is no universal standard for every database engine yet.
In mixed environments, some databases can support native IAM federation, while others need an external proxy to translate identity into session controls. For regulated data stores, teams may require dual approval for write access, query allowlists, or read masking rather than full denial. The key is to avoid treating VPN membership as evidence of authorization. The 52 NHI Breaches Analysis shows how quickly static access assumptions become breach pathways when credentials and privileges are left in place longer than intended. Where databases sit behind brittle network controls or fixed service accounts, this approach loses precision and tends to become a policy on paper rather than an enforced control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses long-lived secrets and excessive standing access to databases. |
| NIST CSF 2.0 | PR.AA-04 | Supports strong identity-based authorisation beyond network location. |
| NIST AI RMF | GOV-4 | Governance is needed when automated agents request database access dynamically. |
Replace static database credentials with short-lived, per-session access and rotate anything still persistent.
Related resources from NHI Mgmt Group
- What do security teams get wrong about trust in zero-trust access models?
- How should security teams decide whether JIT access is safe for non-human identities?
- How should security teams prove privileged access is compliant without relying on manual audits?
- How should security teams replace VPN trust with zero trust access controls?
