Identity, Authentication and Access Control

Introduction

Identity and access control are foundational to database and information security. Confidentiality, integrity and availability cannot be protected if an organisation cannot determine who is requesting access, whether that identity is genuine, what the requester is allowed to do, and whether the access remains appropriate over time.

Identity security is broader than logging in. It includes the complete lifecycle of an account: creation, verification, use, review, modification, suspension and removal. Authentication establishes confidence in an identity. Authorisation determines what that identity may do. Accountability records actions so that users and administrators can be held responsible.

A useful security sequence is:

1. Identification: a subject claims an identity.
2. Authentication: the system verifies the claim.
3. Authorisation: policy determines permitted actions.
4. Accounting or auditing: activity is recorded and reviewed.

These stages are related but not interchangeable. A valid username is identification, not authentication. Authentication does not automatically grant permission to access every resource. A successful login may still be denied access to a particular database table.

Learning Objectives

By the end of this chapter, a learner should be able to:

• explain identity, authentication, authorisation and accountability;
• implement a controlled account lifecycle;
• compare passwords, tokens, biometrics and multi-factor authentication;
• apply secure password and credential-management practices;
• explain discretionary, mandatory, role-based and attribute-based access control;
• design basic privileged access management controls;
• review permissions and identify excessive privilege;
• prevent common forms of privilege escalation;
• evaluate governance, privacy and ethical issues in identity systems.

1. Identity and Access-Control Foundations

Subjects, objects and operations

An access-control decision normally involves four elements:

• a subject, such as a user, service or device, requesting access;
• an object, such as a database, table, record, file or application function;
• an operation, such as read, insert, update, delete or execute;
• a policy, which determines whether the operation is permitted.

For example, a payroll analyst may be a subject, the salary table may be an object, and reading selected columns may be the operation. The policy may permit access during working hours only from an approved device.

Access-control decisions should be based on more than identity alone. Context can include device health, location, time, network, sensitivity of data and risk level. This is particularly important for cloud services and distributed workforces.

Authentication, authorisation and accounting

Authentication answers: “Who are you?” Authorisation answers: “What are you allowed to do?” Accounting answers: “What did you do, and can the event be traced reliably?”

A secure design keeps these concerns separate. A database administrator may authenticate successfully but still require a second approval before exporting an entire customer database. Similarly, an application service account may be authorised to insert transactions but not to alter database security tables.

The principle of least privilege

Least privilege means granting a subject only the permissions required for an approved task, for only as long as necessary. It applies to human users, applications, scripts, databases, containers and operating-system processes.

Least privilege has three dimensions:

• scope: the resources that may be accessed;
• operation: the actions that may be performed;
• duration: how long the permission remains active.

Least privilege reduces the impact of stolen credentials, malicious insiders, software defects and accidental misuse. It must be balanced with operational practicality: permissions that are too restrictive may encourage unsafe workarounds, such as shared accounts or unauthorised data copies.

Other important principles are separation of duties, need to know, fail-safe defaults, complete mediation and accountability. Separation of duties prevents one person from controlling an entire sensitive process. Complete mediation requires access to be checked whenever a protected resource is accessed, rather than only at initial login.

2. Account Lifecycle Management

An account is a controlled representation of an identity. Lifecycle management ensures that access reflects a current business relationship rather than a historical one.

Joiner, mover and leaver processes

A practical lifecycle model is often described as joiner–mover–leaver.

Joiner process: Before an account is created, the organisation should receive an approved request identifying the person, employment or contractual status, department, manager, required systems and start date. Identity proofing should be appropriate to risk. The account should receive a unique identifier, not a shared username.

Mover process: When a person changes department, role or responsibility, old permissions must be reviewed and removed rather than simply adding new permissions. Failure to remove previous access creates privilege accumulation, sometimes called permission creep.

Leaver process: At termination or contract completion, access should be disabled promptly. This includes directory accounts, VPN access, cloud services, database accounts, tokens, API keys, privileged credentials and physical access badges. Ownership of files, scheduled jobs and service dependencies must also be transferred safely.

Account categories

Organisations commonly manage several account types:

Service accounts should have an accountable owner, documented purpose, limited permissions and a rotation mechanism for secrets. Interactive login should be disabled unless required. Shared accounts should be replaced with individually attributable access whenever technically possible.

Provisioning and deprovisioning controls

A mature process normally includes:

1. documented request and business justification;
2. approval by an accountable manager or data owner;
3. identity verification;
4. automated or controlled provisioning;
5. notification to the user;
6. periodic access review;
7. event-driven modification or suspension;
8. secure deprovisioning and evidence retention.

Automation reduces delay and inconsistency, but automation must not blindly copy inaccurate human-resource records. Reconciliation should compare authoritative sources, such as the HR system, directory, cloud identity provider and application inventories.

Access reviews

An access review asks whether each permission is still justified. Reviewers should examine the identity, role, resource, privilege level, business purpose, last use, approval and expiry date. Review evidence should record the decision, reviewer, date and remediation action.

Reviews may be periodic or event-driven. High-risk administrative access generally requires more frequent review than ordinary read access. Merely reviewing group membership is insufficient if nested groups, inherited permissions or application-specific rules grant additional access.

3. Authentication Factors and Methods

Authentication factors are commonly grouped into three categories:

• Knowledge: something the user knows, such as a password or PIN.
• Possession: something the user has, such as a hardware token or registered phone.
• Inherence: something the user is, such as a fingerprint or facial characteristic.

A fourth category, sometimes used in risk-based systems, is location or context, such as a trusted network or device posture. Context alone is generally not a sufficient replacement for a strong independent factor.

Multi-factor authentication (MFA) requires two or more different factor categories. Entering a password and a second password is still single-factor authentication because both are knowledge factors.

Passwords and passphrases

Passwords remain common but are vulnerable to phishing, credential stuffing, password spraying, reuse, malware and weak recovery procedures. Secure practice includes:

• allowing long passwords and passphrases;
• blocking known-compromised passwords;
• storing passwords using a modern, deliberately slow password-hashing function with a unique salt;
• rate limiting or detecting repeated failures;
• avoiding arbitrary forced changes unless compromise is suspected or policy requires it;
• never storing or transmitting plaintext passwords;
• providing secure recovery rather than weak knowledge-based questions.

A salt is a unique random value stored with a password hash. It prevents identical passwords from producing identical stored values and makes precomputed lookup attacks less useful. Hashing is not encryption: a password hash is designed to be difficult to reverse, whereas encrypted data is designed to be decrypted with a key.

Tokens and cryptographic authentication

Possession factors include one-time-password devices, smart cards, security keys and mobile applications. Time-based one-time passwords are commonly generated from a shared secret and a time interval. They improve security over passwords alone but can still be exposed through phishing.

Public-key authentication uses a private key held by the user or device and a public key registered with the service. The private key signs a challenge; the service verifies the signature using the public key. The private key should be protected by hardware or a secure credential store and should not be exported unnecessarily.

Phishing-resistant methods, such as modern cryptographic security keys, bind authentication to the legitimate service origin and are generally stronger against credential-replay attacks than codes manually entered from an authenticator application.

Biometrics

Biometrics can be convenient, but biometric characteristics are not secret in the same way as passwords. A fingerprint or face cannot normally be changed after compromise. Biometric systems should therefore protect biometric templates, minimise collection, provide an alternative factor, test for presentation attacks and consider error rates and demographic performance differences.

Risk-based and adaptive authentication

Adaptive authentication evaluates context such as device status, unusual location, impossible travel, behaviour and transaction sensitivity. It may request additional verification when risk is elevated. Such systems should be explainable enough for legitimate users and administrators to understand decisions. They must not become a reason to collect excessive personal data without governance.

4. Multi-Factor Authentication in Practice

MFA is most effective when it is applied to high-impact paths: administrator accounts, remote access, cloud consoles, password recovery, financial actions and access to sensitive databases. It should cover both the normal login and the recovery process; a strong login can be defeated by a weak account-recovery channel.

A practical MFA deployment includes:

1. identify systems and accounts by risk;
2. select an appropriate factor, preferably phishing-resistant for privileged access;
3. register devices through verified processes;
4. issue recovery codes securely;
5. provide a controlled lost-device procedure;
6. monitor enrolment, failures, bypasses and reset events;
7. test resistance to phishing and social engineering;
8. ensure emergency access is logged and reviewed.

MFA fatigue attacks attempt to persuade a user to approve repeated unexpected prompts. Users should be trained never to approve an unrecognised request. Number matching, transaction details and rate limits can reduce accidental approval, although they do not replace phishing-resistant authentication.

5. Access-Control Models

Discretionary Access Control

In Discretionary Access Control (DAC), the owner of an object may determine who can access it. Traditional file permissions and database grants often have DAC characteristics. DAC is flexible and convenient, but users may unintentionally share information or transfer permissions to others.

A database example is a table owner granting a colleague SELECT permission. The security risk is that ownership and sharing can become difficult to govern in large environments.

Mandatory Access Control

Mandatory Access Control (MAC) uses centrally defined labels and rules. Subjects and objects receive classifications, and users cannot normally change policy at their discretion. A military-style example may classify information as Public, Confidential, Secret or Top Secret. Access depends on clearance and rules concerning information flow.

MAC can provide strong control in high-assurance environments, but classification must be accurate and maintained. It may be less flexible for rapidly changing business teams.

Role-Based Access Control

Role-Based Access Control (RBAC) assigns permissions to roles, and users receive roles according to job responsibilities. For example, a “claims assessor” role may read claim records and update assessment status, while a “claims manager” role may approve settlements.

RBAC simplifies administration and supports separation of duties. However, poorly designed roles create role explosion or overly broad permissions. Roles should represent stable responsibilities, not every individual exception.

RBAC commonly uses:

• role hierarchies, where senior roles inherit permissions from junior roles;
• static separation of duties, preventing conflicting roles from being assigned together;
• dynamic separation of duties, preventing conflicting roles from being used in the same session or transaction.

Attribute-Based Access Control

Attribute-Based Access Control (ABAC) evaluates attributes of the subject, object, action and environment. A policy might state: a clinician may read a patient record when the clinician is assigned to that patient, the purpose is treatment, the device is managed and the session uses strong authentication.

ABAC supports fine-grained and contextual decisions, but policies can become complex. Attributes must be accurate, authoritative and protected from tampering. Organisations need policy testing, conflict resolution and clear explanations of denials.

Many modern systems combine models. A user may receive a role through RBAC, while ABAC conditions restrict use to an approved device and time. This is often described as a risk-adaptive or zero-trust approach: access is continuously evaluated rather than assumed safe merely because a user is inside a network.

6. Privileged Access Management

Privileged accounts can change security settings, create users, modify databases, disable logs or deploy software. Their compromise can therefore produce organisation-wide damage.

Privileged Access Management (PAM) is a set of technical and procedural controls for high-impact access. Important controls include:

• separate administrative and ordinary user accounts;
• just-in-time access that expires automatically;
• approval for sensitive tasks;
• credential vaulting and automated rotation;
• session recording or command logging where lawful and appropriate;
• restrictions on direct database and operating-system access;
• secure emergency access;
• continuous monitoring and alerting;
• periodic review of privileged groups and delegated permissions.

Administrators should not browse email or the web from privileged sessions. Administrative workstations should be hardened, patched and separated from ordinary user activity. Privileged credentials should not be embedded in source code, scripts or configuration files.

Database-specific privileged access

Database administrators may possess powers that bypass application controls. Controls should include separate schema ownership from application runtime accounts, minimal grants, controlled use of superuser functions, protected audit logs, restrictions on bulk export and monitoring of changes to permissions, stored procedures and security tables.

Applications should use service identities with only the SQL operations needed. For example, an online order service may insert orders and read product data but should not drop tables, create users or read unrelated payroll data.

7. Preventing Privilege Escalation

Privilege escalation occurs when an entity gains permissions beyond those intended. It may be vertical, such as a normal user becoming an administrator, or horizontal, such as one customer accessing another customer’s records.

Common causes include:

• excessive default permissions;
• insecure direct object references;
• vulnerable software and unpatched systems;
• misconfigured cloud roles;
• dangerous set-user-ID or administrative services;
• writable scripts executed by privileged processes;
• leaked service-account secrets;
• nested group membership;
• insecure delegation and impersonation;
• application logic that trusts client-supplied role values.

Preventive controls include secure configuration baselines, timely patching, code review, server-side authorisation checks, dependency management, input validation, constrained delegation, protected secrets, separation of duties and continuous monitoring.

A particularly important rule is that authorisation must be enforced on the server or trusted policy engine. A hidden button in a user interface does not protect an operation if the user can call the underlying API directly.

8. Permission Review and Access Certification

Permission review should combine inventory, analysis and remediation. An organisation should know which identities exist, which permissions they hold, how permissions are inherited and whether each grant has a valid owner.

A review workflow can be expressed as:

1. extract accounts, groups, roles, policies and resource permissions;
2. resolve nested and inherited access;
3. classify resources by sensitivity;
4. identify dormant, duplicate, orphaned and excessive accounts;
5. ask an accountable owner to certify or reject access;
6. remove rejected or expired permissions;
7. record evidence and verify completion;
8. investigate anomalies and repeat at an appropriate interval.

Useful indicators include the number of dormant accounts, time taken to disable leavers, percentage of privileged accounts using MFA, number of emergency-access events, unresolved review findings and permissions without an owner. Metrics should support risk reduction rather than encourage superficial completion.

9. Governance, Ethics and Privacy

Identity systems process personal and sometimes sensitive information. Governance should define purpose, data minimisation, retention, access to identity records, audit use and incident response. Biometric data and behavioural analytics deserve particular care because misuse can affect individuals permanently.

Organisations should align controls with applicable law, contractual duties and recognised security frameworks. Regulatory requirements vary by jurisdiction and sector, so legal advice may be needed. Common governance expectations include least privilege, strong authentication for sensitive access, auditable administration, timely revocation and protection of personal data.

Ethically, access decisions should be proportionate, explainable and non-discriminatory. Automated risk scoring may produce false positives or systematically disadvantage some groups. A human review and appeal path is appropriate for consequential decisions such as account suspension or denial of essential services.

10. Illustrative Case: Regional Health-Records Service

Background

A regional health organisation operates a patient-record database, an online portal and several laboratories. Nurses, doctors, reception staff, contractors and applications all require different access. An internal audit discovers that former contractors still have active accounts, several doctors share a departmental login and a laboratory application uses a database account with broad administrative permissions.

Problem

The organisation faces confidentiality risk, weak accountability and possible privilege escalation. A shared account prevents reliable attribution. The laboratory account could alter tables unrelated to laboratory work. Departed contractors could potentially access patient data.

Analysis

The weaknesses are not solved merely by changing passwords. They arise from lifecycle failures, excessive privilege, weak accountability and poor separation between application and administrative access. Patient data is highly sensitive, so access should be based on legitimate role and treatment context.

Approach and solution

The organisation establishes a central identity provider and unique workforce accounts. HR events automatically generate joiner, mover and leaver workflows, with urgent termination notifications for high-risk roles. MFA is required for remote and privileged access, using phishing-resistant security keys for administrators.

RBAC defines baseline roles such as reception, nurse, clinician, laboratory technician and database administrator. ABAC conditions restrict patient-record access to assigned facilities, approved devices and legitimate treatment contexts. Emergency access is available for urgent care but requires a reason, generates an alert and is reviewed afterward.

The laboratory application receives a dedicated service identity. Its permissions are limited to required stored procedures and tables; it cannot create users or modify security configuration. Administrative database access is placed behind PAM with approval, time limits, credential rotation and session logging. Shared departmental accounts are retired, and historical data ownership is reassigned.

Outcome

The organisation can attribute activity to individuals, revoke access promptly and distinguish application activity from administration. Permission reviews identify stale access, while audit alerts highlight unusual bulk exports and emergency-account use. The controls do not eliminate all risk, but they reduce exposure and improve investigation capability.

Learning points

• Identity lifecycle controls are as important as login technology.
• Shared accounts weaken accountability and should be exceptional.
• RBAC provides structure, while ABAC can add context and fine-grained conditions.
• Service accounts require ownership and minimal permissions.
• Privileged activity needs stronger controls than ordinary access.
• Emergency access must be possible, controlled and reviewed.

11. Contemporary Developments and Best Practices

Cloud identity services increasingly provide central federation, conditional access and automated provisioning. Organisations should avoid assuming that cloud-hosted systems are secure by default; misconfigured roles, tokens and trust relationships remain major risks.

Zero-trust architectures treat every request as requiring policy evaluation. The practical meaning is not that trust is impossible, but that network location alone is insufficient. Identity, device state, resource sensitivity and session risk are evaluated together.

Passwordless authentication is expanding through public-key credentials and device-bound authenticators. It can reduce phishing and password reuse, but enrolment, recovery and device replacement must be designed carefully.

Artificial intelligence may assist with anomaly detection, permission recommendations and identity correlation. It should support, not replace, accountable decisions. Models may generate false positives, learn biased patterns or expose sensitive identity data. Human oversight, protected logs and explainable review processes remain necessary.

A concise implementation checklist is:

• maintain an authoritative identity inventory;
• prohibit unnecessary shared accounts;
• automate joiner–mover–leaver workflows;
• apply MFA to privileged and high-risk access;
• prefer phishing-resistant authentication where feasible;
• use least privilege and separation of duties;
• separate administrative from ordinary accounts;
• vault and rotate service credentials;
• review effective permissions, including inheritance;
• monitor and record privileged activity;
• test account recovery and emergency access;
• patch systems and remove dangerous defaults;
• protect identity and biometric data;
• retain evidence of approvals, reviews and remediation.

Chapter Summary

Identity security manages the relationship between people, services, devices and protected resources. Identification claims an identity; authentication verifies it; authorisation determines permitted actions; and accounting provides traceability. Secure organisations manage accounts through joiner, mover and leaver processes, use unique identities, remove stale access and review permissions regularly.

Passwords should be protected with secure hashing and supported by stronger factors. MFA is most valuable for privileged, remote and sensitive access, especially when phishing-resistant methods are used. DAC, MAC, RBAC and ABAC provide different approaches to access decisions. RBAC organises permissions around job responsibilities, while ABAC evaluates attributes and context. These models may be combined.

Privileged access requires additional safeguards, including separate accounts, just-in-time elevation, approval, credential vaulting, monitoring and session review. Privilege escalation is reduced through least privilege, secure configuration, server-side authorisation, patching, protected secrets and effective permission analysis. Governance must address auditability, privacy, proportionality, fairness and applicable legal obligations.

Key Terms

Account lifecycle management: Processes controlling account creation, modification, review, suspension and removal.

Authentication: Verification of a claimed identity.

Authorisation: Determination of which actions a subject may perform.

Attribute-Based Access Control (ABAC): Access control based on subject, object, action and environmental attributes.

Biometric factor: An authentication factor based on a physical or behavioural characteristic.

Complete mediation: Checking access whenever a protected resource is accessed.

Discretionary Access Control (DAC): A model in which an object owner can control access.

Identity proofing: Establishing confidence that an identity corresponds to a real individual or entity.

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

Mandatory Access Control (MAC): Centralised access control based on labels and defined rules.

Multi-factor authentication (MFA): Authentication using two or more different factor categories.

Permission creep: Accumulation of unnecessary access as a person changes responsibilities.

Privileged Access Management (PAM): Controls for managing high-impact administrative access.

Privilege escalation: Gaining permissions beyond those intended.

Role-Based Access Control (RBAC): Assigning permissions to roles and assigning users to roles.

Salt: A unique random value added when storing a password hash.

Separation of duties: Dividing sensitive tasks among different people or roles.

Service account: An identity used by an application, process or automated service.

Subject: An entity requesting access to a resource.

Zero trust: A security approach that continuously evaluates access rather than relying on network location or assumed trust.

Review Questions

5 Short Answer Questions

1. Distinguish identification, authentication and authorisation.
2. What is the purpose of a salt in password storage?
3. Name the three traditional authentication-factor categories.
4. Define privilege creep and explain how it develops.
5. Why should service accounts have an owner and documented purpose?

5 Long Answer Questions

1. Explain the joiner–mover–leaver account lifecycle and identify controls required at each stage.
2. Compare DAC, MAC, RBAC and ABAC, including one advantage and one limitation of each.
3. Describe how MFA should be designed for administrators, including enrolment, recovery and monitoring.
4. Explain the purpose of PAM and discuss at least five controls used to protect privileged access.
5. Discuss the governance, privacy and ethical issues associated with biometric and adaptive authentication.

3 Analytical / Application Questions

1. A contractor changes from database support to application testing, but retains all previous database administrator permissions. Analyse the risks and design a remediation plan.
2. A hospital wants nurses to access patient records only for assigned patients, from managed devices, during authorised shifts. Select and justify an access-control model or combination of models.
3. An application uses a database superuser account stored in a configuration file. Evaluate the weaknesses and propose a safer identity, authorisation, secret-management and monitoring design.

Multiple Choice Questions with Answers

Question 1

Which sequence correctly represents the basic access process?

A. Authorisation, identification, accounting, authentication

B. Identification, authentication, authorisation, accounting

C. Authentication, accounting, identification, authorisation

D. Accounting, authorisation, authentication, identification

Correct Answer: B. Identification, authentication, authorisation, accounting

Question 2

Which example is multi-factor authentication?

A. A password and a PIN

B. Two passwords entered at different times

C. A password and a hardware security key

D. A username and an email address

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

Question 3

What is the main purpose of a password salt?

A. To encrypt the password for later decryption

B. To make identical passwords produce identical hashes

C. To reduce the need for password authentication

D. To make precomputed lookup attacks less useful

Correct Answer: D. To make precomputed lookup attacks less useful

Question 4

Which access-control model assigns permissions primarily to job roles?

A. RBAC

B. DAC

C. MAC

D. ABAC

Correct Answer: A. RBAC

Question 5

Which situation best illustrates privilege creep?

A. A user authenticates with a security key

B. A former administrator retains permissions after changing departments

C. A database records a failed login

D. A password is stored with a unique salt

Correct Answer: B. A former administrator retains permissions after changing departments

Question 6

Which control is most directly associated with privileged access management?

A. Allowing administrators to share one permanent password

B. Disabling all audit logging for performance

C. Providing time-limited approved administrative access

D. Granting every employee database-owner privileges

Correct Answer: C. Providing time-limited approved administrative access

Question 7

A nurse may read a patient record only when assigned to that patient, using a managed device. Which model most naturally expresses these conditions?

A. ABAC

B. DAC only

C. MAC based only on a security label

D. Unauthenticated access control

Correct Answer: A. ABAC

Question 8

Which practice best protects a service account?

A. Allowing interactive login from any device

B. Embedding its password in application source code

C. Giving it permanent database administrator privileges

D. Assigning an owner, limiting permissions and rotating its secret

Correct Answer: D. Assigning an owner, limiting permissions and rotating its secret

Question 9

What is vertical privilege escalation?

A. A user accessing another user’s record at the same privilege level

B. A user gaining a higher privilege level, such as administrator access

C. A user changing a password through an approved process

D. A service account accessing its permitted table

Correct Answer: B. A user gaining a higher privilege level, such as administrator access

Question 10

Why are shared accounts discouraged?

A. They always require biometric authentication

B. They prevent all forms of automation

C. They weaken individual accountability and access review

D. They cannot be used with databases

Correct Answer: C. They weaken individual accountability and access review