implementing-pam-for-database-access

name	implementing-pam-for-database-access
description	Deploy privileged access management for database systems including Oracle, SQL Server, PostgreSQL, and MySQL. Covers session proxy configuration, credential vaulting, query auditing, dynamic credentia
domain	cybersecurity
subdomain	identity-access-management
tags	["iam","identity","access-control","privileged-access","pam","database","dba"]
version	1.0
author	mahipal
license	Apache-2.0
nist_csf	["PR.AA-01","PR.AA-02","PR.AA-05","PR.AA-06"]

Implementing PAM for Database Access

Overview

Deploy privileged access management for database systems including Oracle, SQL Server, PostgreSQL, and MySQL. Covers session proxy configuration, credential vaulting, query auditing, dynamic credential generation, and least-privilege database roles.

When to Use

• When deploying or configuring implementing pam for database access capabilities in your environment
• When establishing security controls aligned to compliance requirements
• When building or improving security architecture for this domain
• When conducting security assessments that require this implementation

Common Misconfigurations & Verification

Database PAM is routinely bypassed because the direct network path to the DB stays open:

• Proxy vaulting but direct port still reachable: credentials are vaulted and a session proxy exists, yet DBAs connect straight to 1521/1433/5432/3306 with their own logins, bypassing audit entirely. Verify the DB host firewall/listener only accepts connections from the PAM proxy IP, then attempt a direct connect from a workstation — it must be refused. Cross-check DB-native audit (pg_stat_activity / SQL Server sys.dm_exec_sessions / Oracle V$SESSION) and confirm every client_addr is the proxy.
• Shared DBA accounts not vaulted / no per-user attribution: confirm sa, SYS, postgres, root@% are checked out through PAM and that proxy logs map each session to a named human, not a shared login.
• No automatic rotation after checkout: if the vaulted password is not rotated on check-in, a DBA who memorized it retains direct access. Confirm one-time-use / rotate-on-checkin is enabled and test that the previous password fails.
• Query auditing captures connect but not statements: verify the proxy logs actual SQL (not just session start/stop) and that privileged statements (GRANT, DROP, bulk SELECT on PII) trigger alerts.
• Least-privilege roles bypassed via direct superuser grant: confirm vaulted accounts use scoped roles, not blanket DBA/sysadmin/SUPERUSER.
• Dynamic credential users left orphaned: if using dynamic DB creds, confirm expired users are dropped (no accumulating v-* roles) and SIEM receives all PAM session events.