Identity, Authentication and Privileged Access

Introduction and Context

Database security begins with a reliable answer to three questions: Who or what is requesting access? How was that identity verified? What is it permitted to do? These questions correspond to identity, authentication and authorization. In practice, they are inseparable from account provisioning, password policy, multifactor authentication (MFA), federation, service identities, separation of duties (SoD) and privileged access management (PAM).

A database may contain financial records, health information, examination results, customer data or intellectual property. A technically strong database can still be compromised if an employee receives excessive permissions, a service account uses a shared password, or an administrator authenticates through an unprotected channel. Identity and access controls therefore form a security boundary around data and database operations.

This chapter explains how to design and operate these controls in a professional environment. It distinguishes authentication from authorization, examines human and non-human identities, and presents practical control processes for the database lifecycle.

Learning Objectives

After completing this chapter, you should be able to:

1. Distinguish identity, authentication, authorization, accounting and auditing.
2. Design secure account provisioning and deprovisioning processes.
3. Explain password controls and the operation and limitations of MFA.
4. Describe federation and the role of standards such as SAML, OAuth 2.0 and OpenID Connect.
5. Manage service identities and secrets securely.
6. Apply separation of duties and least privilege to database administration.
7. Explain the purpose and operation of privileged access management.
8. Evaluate identity controls in an applied database-security scenario.

1. Identity and Access as a Security Model

An identity is a distinguishable representation of a person, application, device or process. An identity may be represented by a username, an email address, a directory object, a certificate subject or a workload identity. Authentication is the process of establishing confidence that an entity controls the claimed identity. Authorization determines which actions that authenticated identity may perform. Accounting records what occurred, when it occurred and which identity performed the action; this is commonly called auditing or accountability.

A useful access decision can be expressed conceptually as:

Here, subject is the requesting identity, action is the requested operation, resource is the database object or service, and context may include time, network location, device state, risk and transaction purpose. The expression is a policy model rather than a numerical equation. A secure design evaluates more than the username alone.

The principal access principles are:

• Least privilege: grant only the permissions needed for an approved task.
• Need to know: restrict access to information required for a legitimate role.
• Default deny: reject access unless an explicit policy permits it.
• Separation of duties: divide sensitive activities among different people or roles.
• Accountability: use individual identities and reliable logs rather than anonymous or shared access.
• Fail safely: when identity services or policy checks fail, access should normally be denied or restricted.
• Lifecycle control: create, modify, review, suspend and remove accounts in a controlled manner.

A role-based access control (RBAC) model assigns permissions to roles and roles to users. For example, a reporting analyst may receive SELECT permission on approved views but not direct access to underlying salary tables. An administrator may manage database configuration but not approve their own access request. Attribute-based access control (ABAC) adds attributes such as department, data classification, location or time. Many modern systems combine RBAC and ABAC.

2. Account and Access Lifecycle

Identity security is a lifecycle, not a one-time provisioning event. The lifecycle normally contains the following stages:

1. Request: a manager or system owner identifies a business need.
2. Approval: the data owner, application owner or security authority approves access.
3. Provisioning: an account is created and assigned an appropriate role.
4. Authentication setup: credentials, MFA and recovery procedures are registered.
5. Use and monitoring: activity is logged and anomalous behavior is investigated.
6. Review: access is periodically recertified and adjusted.
7. Change: transfers, promotions and changed duties trigger re-evaluation.
8. Suspension or termination: access is disabled promptly when no longer justified.
9. Evidence retention: approvals, changes and removal are retained according to policy.

Provisioning should be based on an authoritative source, such as a human-resources system for employees or a configuration-management system for workloads. Manual creation in multiple databases creates inconsistent identities and orphaned accounts.

A practical provisioning record should contain the requester, business justification, data owner, role, start and expiry dates, approval evidence, MFA status and system administrator who performed the change. Temporary access should have an automatic expiry rather than relying on memory.

Joiner, mover and leaver controls are especially important. A joiner receives only the access required for the new position. A mover has old permissions removed before or as new permissions are granted. A leaver is disabled immediately when employment or contract authority ends. Emergency termination procedures should be tested, because a delay may allow misuse of active credentials.

Periodic access reviews should be risk-based. Privileged database accounts, production access and access to regulated data deserve more frequent review than low-risk read-only access. Reviewers should confirm actual business need rather than merely approving a list automatically.

3. Authentication Factors and Password Controls

Authentication factors are traditionally grouped into:

MFA uses two or more independent factors. Two passwords are not genuine MFA because both are knowledge factors. A password plus a phishing-resistant security key is stronger because compromise of the password alone is insufficient.

Password storage and verification

Systems must not store plaintext passwords. They should store a salted, computationally expensive password hash produced by a password-hashing algorithm designed for this purpose, such as Argon2id, scrypt or bcrypt. A salt is a unique random value stored with the hash; it prevents identical passwords from producing identical stored values and reduces the usefulness of precomputed tables.

Password hashing is not encryption. Encryption is reversible with a key; password hashing is intended to be one-way, with verification performed by hashing the submitted password and comparing the result through a secure verification function.

Good password controls include:

• blocking known compromised passwords;
• permitting long passphrases and password managers;
• rate limiting and account lockout designed to resist denial of service;
• secure password-reset processes;
• protecting reset tokens with short lifetimes and single use;
• avoiding arbitrary periodic changes unless compromise or risk justifies them;
• preventing passwords from appearing in logs, URLs or source code;
• requiring stronger authentication for privileged actions.

Password policy should balance resistance to guessing with usability. Excessive complexity rules can encourage predictable patterns and unsafe reuse. Password managers and phishing-resistant MFA usually provide more security than forcing frequent, short changes.

Multifactor authentication

MFA reduces the impact of stolen passwords, but it is not equally strong in every form. SMS codes can be exposed through number reassignment, interception or social engineering. Email codes depend on the security of the email account. One-time-password applications are stronger, but phishing sites may relay codes in real time. Hardware security keys using modern public-key protocols provide strong phishing resistance because authentication is bound to the legitimate website origin.

MFA enrollment and recovery are critical attack points. Enrollment should require an already trusted factor or supervised identity proofing. Recovery should not silently reduce security to a weak help-desk process. Administrators should receive more robust factors and should not rely solely on personal phones where organizational alternatives are required.

4. Federation and Single Sign-On

Federation allows one identity provider (IdP) to authenticate a user for a separate service provider (SP). This avoids maintaining independent passwords in every application. Single sign-on (SSO) improves usability and centralizes policy, but it also makes the IdP highly sensitive: compromise of the IdP may affect many databases.

Common technologies include:

• SAML: an XML-based protocol commonly used for browser-based enterprise SSO.
• OAuth 2.0: an authorization framework for delegated access; it is not, by itself, an authentication protocol.
• OpenID Connect (OIDC): an identity layer built on OAuth 2.0, using identity tokens and claims.
• Kerberos: a ticket-based authentication protocol widely used in enterprise directory environments.

In federated access, the database or database gateway must validate issuer, audience, signature, expiry, nonce where applicable and required claims. Trust must be established through carefully managed keys and metadata. A token that is validly signed is not necessarily valid for every service; its intended audience and authorization claims must also be checked.

Federation should use unique subject identifiers, not mutable email addresses as the sole identity key. Role or group claims should be mapped conservatively. A claim such as Admin should not automatically grant unrestricted production access without additional approval and context.

Federation introduces risks including token theft, misconfigured redirect URIs, excessive claim privileges, signing-key compromise and dependence on the identity provider. Organizations should plan for IdP outage, key rotation, emergency revocation and a secure break-glass account.

5. Service Identities and Non-Human Accounts

A service identity represents an application, batch job, integration, database agent or automated process. It should be distinct from a human account. Shared human credentials used by applications destroy accountability and create difficult password-rotation problems.

Service identities should have:

• a named owner and documented purpose;
• narrowly scoped permissions;
• separate identities for development, testing and production;
• no interactive login unless explicitly required;
• secrets stored in a secrets manager or protected keystore;
• automatic rotation where feasible;
• monitoring for unusual use;
• an expiry or review date;
• a documented dependency and recovery procedure.

Long-lived static passwords embedded in scripts are a common failure. Better approaches include short-lived tokens, workload identity, mutual TLS certificates or managed identities supplied by a cloud or enterprise platform. A secret manager should control retrieval, authorization, encryption, rotation and audit. Merely placing a password in an encrypted configuration file is not a complete identity-management solution if every application operator can decrypt it.

A service account should not be granted broad database ownership merely because an application currently fails with a permission error. The error should lead to analysis of the required operation, followed by narrowly scoped permissions, stored procedures or approved views where appropriate.

6. Separation of Duties and Privileged Access

Separation of duties reduces the possibility that one person can complete and conceal a sensitive action. A database change process might separate:

• the developer who writes a migration;
• the reviewer who approves it;
• the operator who deploys it;
• the business owner who confirms the outcome.

SoD can be preventive, blocking incompatible role combinations, or detective, identifying conflicts through review. Some small organizations cannot fully separate roles; compensating controls may include dual approval, independent logging, session recording and post-event review.

A privileged account can make high-impact changes, such as altering permissions, disabling auditing, reading protected tables, changing encryption settings or modifying production schemas. Privileged access management is a collection of technical and administrative controls that govern such access.

A mature PAM arrangement commonly includes:

1. discovery of privileged accounts and credentials;
2. elimination of unnecessary administrator accounts;
3. separate standard and administrative identities;
4. approval and time-limited elevation;
5. password or key vaulting and rotation;
6. session monitoring and, where lawful, recording;
7. command control or just-in-time access;
8. alerts for unusual privileged activity;
9. emergency access with documented break-glass procedures;
10. periodic review and removal of dormant privileges.

Standing privilege is convenient but dangerous. Just-in-time access grants privilege only for an approved period and reduces the time available for misuse. It does not remove the need for careful approval: an attacker may exploit a valid temporary grant if the request process is weak.

Database administrators should generally use named administrative accounts rather than a shared root, sa or equivalent account. A break-glass account may exist for service continuity, but its use should trigger immediate alerting, strong protection and independent review.

Figure: A controlled privileged-access lifecycle with feedback from monitoring to review.

7. Auditing, Risk and Governance

Identity controls are effective only when they produce evidence. Logs should record successful and failed authentication, MFA events, privilege elevation, role changes, password resets, administrative commands and access to sensitive objects. Logs should use synchronized clocks, resist unauthorized alteration and be sent to a protected central monitoring system.

Logging must be proportionate and lawful. Privacy regulations may restrict excessive collection, employee monitoring or indefinite retention. Organizations should define purpose, access restrictions, retention periods and disclosure procedures. Audit data itself may contain sensitive usernames, queries or personal information.

Risk-based controls are appropriate. A read-only analyst account, a payroll administrator and a database superuser do not require identical controls. Risk assessment should consider data sensitivity, privilege, exposure, likelihood of compromise, business impact and recovery capability. High-risk operations should require stronger authentication, dual control and more detailed monitoring.

Identity governance should align with applicable law, contractual obligations and recognized security frameworks. Examples include access-control requirements in ISO/IEC 27001 programs, NIST digital identity guidance and privacy or sector-specific regulation. Compliance does not automatically mean security; a checklist may be satisfied while excessive permissions remain. Governance must connect policy, ownership, technology and review.

8. Applied Case: Northbridge College Records Platform

Background

Northbridge College operates a central database containing student records, grades, payroll data and research information. Faculty members use SSO, while applications exchange data through service accounts. A small IT team administers production databases.

Problem

An audit found that a former contractor still had an active account, several applications shared one database password, and two administrators used a common superuser account. MFA was enabled for the college portal but not for direct administrative access. Access reviews were informal, and deployment personnel could approve their own database changes.

Analysis

The weaknesses affected confidentiality, integrity and accountability. The former contractor represented a leaver-control failure. Shared service credentials prevented reliable attribution and made rotation risky. A common superuser account defeated individual accountability. Portal MFA did not protect direct database access, and self-approval violated separation of duties.

Approach and solution

The college established the HR directory as the authoritative source for employee status and automated disabling of accounts when contracts ended. It introduced role-based groups for faculty, registry staff, reporting analysts and database administrators. Sensitive tables were exposed through approved views, limiting direct table access.

Applications received separate service identities for development, test and production. Secrets were moved to a managed vault, with rotation and retrieval logging. Direct administrator access required a named account, phishing-resistant MFA and approved time-limited elevation through a PAM gateway. The shared superuser account was disabled except for a protected emergency procedure.

A deployment workflow was introduced in which developers submitted changes, an independent reviewer approved them and an operator deployed them. Database logs and PAM events were forwarded to the security-monitoring team. Quarterly reviews were supplemented by immediate reviews after role changes.

Outcome

The college improved attribution, reduced standing privilege and made account removal more reliable. The changes did not eliminate all risk: compromised administrator endpoints, malicious insiders and identity-provider outages remained possible. Accordingly, the college added endpoint controls, break-glass testing and independent review of high-risk actions.

Learning points

The case demonstrates that identity security is socio-technical. Technology such as MFA and a vault is valuable, but it must be supported by ownership, approval, lifecycle integration, monitoring and tested procedures. The strongest control is ineffective if users bypass it through shared accounts or undocumented emergency access.

9. Challenges and Contemporary Developments

Cloud databases and container platforms increasingly use workload identities instead of static credentials. Zero-trust architectures continuously evaluate identity, device, context and requested resource rather than assuming that an internal network is trustworthy. Passwordless authentication is expanding through passkeys and public-key credentials, although recovery, device loss and organizational interoperability require careful planning.

Artificial intelligence can assist with access analytics by identifying unusual login locations, impossible travel, abnormal query patterns or privilege escalation. Such systems should support—not replace—human investigation. False positives can overwhelm analysts, while opaque models may unfairly affect users. Training data, privacy, explainability and appeal processes must be addressed.

Common implementation limitations include legacy databases that lack modern MFA, inconsistent identity stores, emergency operations that bypass normal controls, excessive administrative convenience and insufficient staffing for access reviews. Migration should be staged: discover accounts, classify risk, remove obvious excess, introduce stronger authentication, then automate lifecycle and monitoring.

Best-Practice Implementation Checklist

• Maintain an inventory of human, service, device and emergency identities.
• Assign every identity an owner, purpose and lifecycle status.
• Integrate joiner, mover and leaver events with authoritative sources.
• Enforce least privilege through roles, views and narrowly scoped service permissions.
• Use phishing-resistant MFA for privileged and high-risk access.
• Hash passwords with an appropriate password-hashing algorithm and unique salts.
• Store secrets in a managed vault; never embed them in code or logs.
• Use named administrative accounts and eliminate routine shared accounts.
• Apply time-limited elevation and independent approval for sensitive actions.
• Record authentication, authorization changes, elevation and database activity.
• Review privileged and sensitive access on a defined schedule.
• Test revocation, recovery, break-glass access and identity-provider failure.
• Protect privacy and retain audit evidence only as long as justified.

Chapter Summary

Identity security establishes the subject behind a database request, authentication verifies that subject, authorization limits permitted actions, and auditing provides accountability. Secure access depends on the complete identity lifecycle: request, approval, provisioning, use, review, change and removal. Least privilege, default deny and separation of duties reduce the impact of error and compromise.

Password controls should use secure password hashing, unique salts, sensible resistance to guessing and safe recovery. MFA is strongest when independent and phishing-resistant. Federation can simplify enterprise access through an identity provider, but tokens, claims, signing keys and outage procedures require careful governance. Service identities need ownership, narrow permissions, protected secrets and rotation. Privileged access management adds discovery, vaulting, approval, time-limited elevation, monitoring and review. Effective implementation combines technology with accountable processes, privacy protection, testing and continuous improvement.

Key Terms

Identity: A representation of a person, process, device or service.

Authentication: Verification that an entity controls a claimed identity.

Authorization: A decision about which actions an authenticated identity may perform.

Accountability: The ability to associate an action with a responsible identity.

Least privilege: Granting only the permissions necessary for an approved task.

RBAC: Access control based on roles assigned to users or services.

ABAC: Access control based on attributes of subjects, resources and context.

MFA: Authentication using two or more independent factors.

Password hash: A one-way computational representation used to verify a password.

Salt: A unique random value combined with a password before hashing.

Federation: Trust between separate identity and service domains.

Identity provider: A system that authenticates identities and issues assertions or tokens.

Service identity: A non-human identity used by an application or process.

Separation of duties: Dividing sensitive responsibilities to reduce abuse and error.

Privileged account: An account capable of high-impact administrative actions.

PAM: Controls for governing, monitoring and limiting privileged access.

Just-in-time access: Privilege granted only for an approved, limited period.

Break-glass account: An emergency account used when normal access processes fail.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization.
2. Why are shared administrator accounts a security weakness?
3. What is the purpose of a salt in password storage?
4. Give two examples of service-identity controls.
5. What does just-in-time privileged access mean?

Long Answer Questions

1. Explain the complete joiner–mover–leaver identity lifecycle and identify control failures that may occur at each stage.
2. Compare RBAC and ABAC, including a suitable database example for each.
3. Explain how federation works and discuss the security responsibilities of an identity provider and a service provider.
4. Describe a mature PAM program for production database administration.
5. Discuss the relationship between MFA, password controls, account recovery and phishing resistance.

Analytical / Application Questions

1. A reporting application uses one password shared by its development, test and production deployments. Analyze the risks and propose a replacement design.
2. A database administrator requests permanent unrestricted access because emergency incidents are frequent. Evaluate the request using least privilege, SoD and PAM principles.
3. Design an access-control and audit approach for a college database containing student grades, payroll records and public reports. Justify different controls for each data category.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorization?

A. Authentication determines what a user may do; authorization identifies the user.

B. Authentication verifies an identity; authorization determines permitted actions.

C. Authentication records events; authorization encrypts passwords.

D. Authentication creates backups; authorization restores databases.

Correct Answer: B. Authentication verifies an identity; authorization determines permitted actions.

Question 2

Which combination represents genuine multifactor authentication?

A. Two different passwords

B. A username and an email address

C. A password and a hardware security key

D. A PIN and a memorable phrase

Correct Answer: C. A password and a hardware security key

Question 3

What is the primary purpose of a unique password salt?

A. To make passwords reversible

B. To allow administrators to read passwords

C. To prevent identical passwords from producing identical stored values

D. To replace the need for password hashing

Correct Answer: C. To prevent identical passwords from producing identical stored values

Question 4

Which practice is most appropriate for a production service identity?

A. Use a shared administrator password embedded in source code

B. Use a named identity with narrow permissions and a managed secret

C. Permit unrestricted interactive login for troubleshooting

D. Use the same credential in development and production

Correct Answer: B. Use a named identity with narrow permissions and a managed secret

Question 5

OAuth 2.0 is primarily an authorization framework, while which technology adds an identity layer?

A. OpenID Connect

B. FTP

C. SNMP

D. SMTP

Correct Answer: A. OpenID Connect

Question 6

Which example best demonstrates separation of duties?

A. One administrator requests, approves and deploys a change

B. All staff use one shared database account

C. A developer writes a change and an independent operator deploys it after approval

D. A service account receives every database permission

Correct Answer: C. A developer writes a change and an independent operator deploys it after approval

Question 7

What is the main purpose of just-in-time privileged access?

A. To create permanent administrator access

B. To grant privilege only for an approved limited period

C. To remove the need for audit logs

D. To permit anonymous administration

Correct Answer: B. To grant privilege only for an approved limited period

Question 8

Which event should normally trigger immediate account deprovisioning?

A. A routine database backup

B. An employee or contractor leaving the organization

C. A successful read-only query

D. A scheduled access review

Correct Answer: B. An employee or contractor leaving the organization

Question 9

Why should an organization use named administrative accounts instead of a shared superuser account?

A. Named accounts improve individual accountability and attribution

B. Named accounts eliminate the need for authorization

C. Shared accounts provide stronger audit evidence

D. Named accounts prevent all endpoint compromise

Correct Answer: A. Named accounts improve individual accountability and attribution

Question 10

Which control most directly protects against a stolen password being used alone for privileged access?

A. Longer database table names

B. Multifactor authentication

C. More frequent backups

D. Disabling audit logs

Correct Answer: B. Multifactor authentication