DBA Privileged Access: Named Accounts, Elevation and Oversight for Database Administrators

Database administrators hold the keys to the data most attackers want, and in many organisations they still do it through shared superuser logins with standing rights and little oversight. Database security guides usually focus on application and service accounts; this one covers the human side across engines: named DBA accounts, splitting the superuser role into smaller roles, just-in-time elevation, session control, audit that the DBA cannot switch off, and separation of duties between DBAs, security and data owners. It is written for DBA leads, privileged access teams and auditors. Engine examples use Microsoft SQL Server, Oracle Database, PostgreSQL and Amazon RDS documentation. For overall database hardening see the Database Security Guide; for engine detail see the Oracle Database Security Guide and the PostgreSQL Security Guide.

Key takeaways

• One person, one DBA account. Shared logins such as sa, postgres, SYS or the RDS master user should be vaulted break-glass accounts, never daily tools.
• Superuser is rarely the job. Modern engines split DBA work into granular roles for monitoring, maintenance, backup, login management and key management; most daily tasks need none of the full superuser rights.
• Elevate on demand. Grant high-privilege roles for a ticketed window and remove them automatically, so standing superuser membership trends to zero.
• Audit must survive the auditor's subject. Ship database audit records off the server to a store DBAs cannot modify, and alert on changes to the audit configuration itself.
• Separate who administers, who grants and who reads. The person who manages logins should not also approve data access or review the audit trail.

Why DBA access needs its own model

A database administrator can read every row, change audit settings, create logins, restore backups to another server and often run operating system commands from inside the engine. Several engines document routes from apparently limited roles to full control:

• SQL Server: Microsoft says to treat securityadmin as equivalent to sysadmin, and to treat principals holding CONTROL SERVER as identical to sysadmin members because of escalation paths. Members of bulkadmin can potentially elevate privileges.
• PostgreSQL: the documentation warns that pg_read_server_files, pg_write_server_files and pg_execute_server_program bypass database permission checks and could be used to gain superuser-level access.
• Managed databases: the Amazon RDS master user receives broad rights (for example the rds_superuser role on RDS for PostgreSQL and the DBA role on RDS for Oracle), and AWS strongly recommends not using it directly in applications.

Generic privileged access controls apply, but they need translating into each engine's role model. See the Privileged Access Management Guide for the general framework.

Splitting the superuser: granular roles by engine

The table maps common DBA tasks to the narrower roles each engine documents. Use these as the standing grants and keep full superuser for elevation only.

Two cautions from vendor documentation. Microsoft notes that ##MS_SecurityDefinitionReader## lets members view password hashes, for example in sys.sql_logins, so assign it only to trusted administrators and security staff. PostgreSQL notes that pg_read_all_data and pg_write_all_data do not bypass row-level security, so administrators may need BYPASSRLS; treat any role with both as a full data reader.

Named accounts and authentication

• Federate where the engine allows: use directory authentication (Windows or Microsoft Entra authentication for SQL Server and Azure SQL, Kerberos or LDAP for PostgreSQL and Oracle) so DBA accounts follow the joiner, mover and leaver process. See the Joiner-Mover-Leaver Guide.
• Use short-lived tokens on managed services: Amazon RDS IAM database authentication for MariaDB, MySQL and PostgreSQL issues tokens valid for 15 minutes. On RDS for PostgreSQL, a user granted rds_iam must sign in with IAM, which removes the password path for that user. Note that AWS states CloudWatch and CloudTrail do not log IAM authentication or generate-db-auth-token calls, so keep database-side login auditing on.
• Require MFA upstream: most database protocols cannot prompt for MFA, so enforce it at the bastion, privileged access workstation or PAM broker that the DBA must pass through. See the Privileged Access Workstations Guide.
• Vault the built-in superusers: keep sa, postgres, SYS and the RDS master user in a vault with check-out approval and rotation after each use. On RDS, AWS can manage the master user password in AWS Secrets Manager. See the Break-Glass Account Guide.
• Keep two accounts per DBA: a standard account for email and tickets, and a separate DBA account used only from the admin path (NIST SP 800-53 AC-6(2)).

Just-in-time elevation and session control

The aim is that no human holds sysadmin, superuser or SYSDBA by default. The pattern below is an NHI Mgmt Group recommendation:

Elevation can be implemented by a PAM tool adding and removing role membership, by a broker issuing a temporary credential, or, on managed services, by granting a short-lived IAM permission to connect as a privileged database user. See the JIT Access Guide and the Privileged Session Management Guide.

Audit the DBA can't switch off

DBA activity should be logged by the engine and copied off the server quickly (NIST SP 800-53 AC-6(9) and AU-9(4)).

• SQL Server Audit: server audit specifications with SERVER_ROLE_MEMBER_CHANGE_GROUP, DATABASE_ROLE_MEMBER_CHANGE_GROUP, SERVER_PERMISSION_CHANGE_GROUP, SERVER_PRINCIPAL_CHANGE_GROUP, LOGIN_CHANGE_PASSWORD_GROUP, FAILED_LOGIN_GROUP, SUCCESSFUL_LOGIN_GROUP and AUDIT_CHANGE_GROUP. Microsoft notes that audits are disabled when first created, and that SCHEMA_OBJECT_ACCESS_GROUP at server scope can be very high volume, so use database-level audits for specific sensitive tables.
• PostgreSQL with pgAudit: session logging classes ROLE (grants, revokes and role changes), DDL, MISC_SET (including SET ROLE) and, for sensitive tables, object audit logging through pgaudit.role.
• Oracle Database: unified auditing policies covering administrative users and privilege use; see the Oracle Database Security Guide.
• Protect the trail: write audit records to a destination outside the DBA's control, such as a SIEM or write-once storage owned by security, and alert on any change to audit specifications or on a gap in records.

Separation of duties

Small teams cannot always split every duty. Where one person must cover two rows, compensate with recorded sessions and a monthly review of that person's activity by someone outside the team.

Managed databases and the cloud control plane

On managed services the DBA role is split between two planes, and both need controlling.

• Control plane: cloud permissions to modify an instance, reset the master password, take or share snapshots, or change parameter groups are DBA-equivalent. Anyone who can reset the master password can become the superuser, and anyone who can share a snapshot can copy the data out. Treat these cloud permissions as privileged and include them in DBA reviews.
• Data plane: the engine roles described above still apply inside the managed database. The master user is the managed equivalent of the built-in superuser and belongs in the vault.
• Restore paths: a restore of a production snapshot into another account or a developer project carries every login, role and password hash with it. See the Environment Separation guide for the controls on non-production copies.

Choosing an approach for your size

Implementing the programme

1. Discover: list members of sysadmin, securityadmin and CONTROL SERVER holders; PostgreSQL superusers and members of the server file roles; Oracle users with DBA or administrative privileges; and every managed database master user. Include service accounts so you do not mistake them for people.
2. Map tasks to roles: interview DBAs about what they actually do each week and match it to the granular roles above.
3. Turn on audit first: enable the audit groups or pgAudit classes and ship them off-server before changing access, so you have a baseline and can prove no task was missed.
4. Pilot one estate: move a non-production estate to named accounts, granular roles and elevation for two weeks. Track every elevation request to find missing standing roles.
5. Roll to production in waves: by business criticality, keeping the previous role memberships recorded so a single DBA can be restored within an hour if an outage needs it.
6. Vault the built-ins: rotate and vault the built-in superuser passwords last, once named access is proven, and test break-glass check-out.
7. Review quarterly: certify standing DBA roles with data owners. See the Access Reviews Guide.

Detection and measurement

Alert on: role membership changes to superuser roles outside an elevation record, use of built-in superuser accounts, audit configuration changes, logins from outside the admin path, large exports or COPY to files, and restores to unexpected servers. Database activity monitoring tools can help at scale; see the Database Activity Monitoring buyer's guide.

• Standing superusers: humans with full superuser outside elevation (target: zero, or break-glass only).
• Shared account use: sessions using built-in superusers per month, each with a matching approval.
• Elevation hygiene: percentage of elevations with a ticket and automatic expiry.
• Audit coverage: percentage of production instances shipping audit records off-server, and maximum gap in records.
• Review completion: DBA role certifications completed on time.

Framework mapping

Common failure patterns

• Everyone is sysadmin: the DBA team, the backup tool and two developers sit in the top role because it was easier during a migration and never reverted.
• securityadmin treated as safe: login managers given securityadmin on the assumption it is weaker than sysadmin, despite Microsoft's guidance to treat it as equivalent.
• Server file roles granted for one import: pg_read_server_files or pg_execute_server_program granted for a data load and left in place, creating a path to superuser-level access.
• Instructions instead of permissions: a change freeze announced but not enforced in role membership. The Replit AI Agent Database Deletion 2025 shows that standing production write access ignores instructions; the same is true for people under pressure.
• Audit on the same box: audit files written locally where the superuser can stop or delete them.
• Master user in the application: the managed database master user embedded in an application configuration, so every developer with config access is a DBA.

For how applications and services store and rotate the database credentials they use, see our Database Credential and Access Security Guide; this guide covers the people who administer the database.

Practitioner checklist

• Inventory every human and machine holder of superuser, security administration and administrative privileges per engine.
• Give each DBA a named account federated to the directory, separate from their daily account.
• Map weekly DBA tasks to granular roles and grant those as standing access.
• Move full superuser to time-limited elevation with a ticket and a second approver.
• Vault and rotate built-in superusers and managed database master users.
• Broker production DBA sessions with MFA and recording.
• Enable engine audit for role, permission, login and audit changes and ship it off-server.
• Split login management, data access approval and audit review between different people.
• Certify DBA access quarterly with data owners.

Standards and references

• NIST: SP 800-53 Rev 5 Security and Privacy Controls
• Microsoft Learn: SQL Server server-level roles
• Microsoft Learn: SQL Server Audit action groups and actions
• PostgreSQL: Predefined roles
• pgAudit: PostgreSQL Audit Extension documentation
• Oracle: Configuring privilege and role authorisation
• AWS: Master user account privileges for Amazon RDS
• AWS: IAM database authentication for Amazon RDS

Related NHI Mgmt Group resources: Database Security Guide · Privileged Access Management Guide · JIT Access Guide · MySQL Security Guide