Notifications
Clear all
Topic starter
17/08/2026 4:41 pm
TL;DR: Database access controls are shifting from shared accounts and coarse roles toward automated provisioning, object-level permissions, and policy-driven auditing, according to Teleport. The core issue is not access alone but whether database entitlements stay granular, traceable, and aligned with identity governance as environments and data partitions grow.
NHIMG editorial — based on content published by Teleport: How Database Access Controls Evolved to Meet Modern Security Needs
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should teams implement least privilege for database access in multi-environment setups?
A: Start by separating access by environment, data class, and job function instead of granting broad database roles.
Q: Why do shared database accounts create governance problems for IAM teams?
A: Shared database accounts break attribution, weaken offboarding, and make access reviews almost meaningless because no one identity owns the activity.
Q: What breaks when database account provisioning is manual?
A: Manual provisioning creates delays, inconsistent naming, and accounts that survive after the need for access has ended.
Practitioner guidance
- Separate shared database access from individual identity access Replace reusable database logins with per-user or per-workload accounts tied to policy and session logging.
- Apply object-level deny rules to sensitive data boundaries Identify tables and schemas that contain regulated, confidential, or high-risk data, then enforce deny rules at the object level before broadening read permissions elsewhere.
- Automate database account offboarding with identity lifecycle events Trigger revocation when a user changes role, leaves a team, or a workload is decommissioned.
What's in the full article
Teleport's full blog post covers the operational detail this post intentionally leaves for the source:
- Role examples showing how database roles are structured for dev and staging environments.
- Object-level permission syntax and deny-rule patterns for tables, schemas, and sensitive data boundaries.
- Custom import rules for adding labels based on database properties and business context.
- Policy visualisation examples that show how Teleport Identity Security represents database object access.
👉 Read Teleport's blog on database access controls and object-level permissions →
Database access controls: are your controls keeping up with modern needs?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
17/08/2026 4:46 pm
Database access control is now an NHI governance problem, not just a DBA problem. Shared accounts, long-lived database users, and manual provisioning are all identity failures dressed up as operational convenience. When database access is granted through reusable credentials, the organisation loses reliable attribution and lifecycle control. The practitioner conclusion is straightforward: database entitlement design must be governed as part of NHI and PAM, not left to ad hoc infrastructure practice.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
A question worth separating out:
Q: Who is accountable when database object permissions are too broad?
A: Accountability sits with the identity, access, and database governance owners together, because broad object permissions are a policy design choice, not a technical accident. If sensitive schemas are exposed through a general role, the organisation has failed to define the boundary clearly enough for audit and review. Compliance teams should expect evidence of object-level intent, not only database-level access lists.
👉 Read our full editorial: Database access controls are moving toward object-level precision
