What it means
Database credential and service-account security limits how nonhuman identities are created, stored, rotated, monitored, and granted database privileges.
Why it matters
Long-lived shared secrets and ownerless service accounts provide durable access that often survives personnel, application, and architecture changes.
Practical focus
- Define the scope, owners, acceptable risk, and required outcome for database credential and service-account security before choosing a tool or platform feature
- Implement unique workload identities, managed secrets, narrow privileges, rotation, ownership, and behavior monitoring through documented, reviewable configuration and change control
- Collect secret age, failed authentication, account use, privilege changes, ownership attestations, and rotation results and compare the results with approved baselines, service objectives, and policy requirements
- Exercise a hard-coded or abandoned credential being copied, leaked, or used outside its approved workload as a planned test case, including detection, containment, rollback, escalation, and evidence retention
Common mistakes
- Treating database credential and service-account security as a one-time technical setting instead of an operating control with owners and review cycles
- Using default thresholds or broad exceptions without connecting them to business, privacy, security, and availability requirements
- Keeping evidence in disconnected tools so reviewers cannot reconstruct who changed what, why it changed, or whether it worked
- Testing only the normal path and discovering during an incident that a hard-coded or abandoned credential being copied, leaked, or used outside its approved workload was never rehearsed
Certification relevance
This subject appears in or supports the following certification bodies of knowledge: