Foundations of Database and Information Security

Introduction and Context

Modern organisations depend on information systems to record transactions, deliver services, make decisions and demonstrate compliance. A hospital uses databases for patient records, a bank for accounts and payments, and an online retailer for customers, products and orders. These systems create value, but they also create risk. Inaccurate, unavailable, altered or disclosed information can cause financial loss, operational disruption, legal liability and harm to individuals.

Database security and information security are closely related but not identical. Database security focuses particularly on protecting databases, database management systems (DBMSs), database accounts, queries, stored procedures, backups and database infrastructure. Information security has a broader scope: it protects information in databases, files, applications, paper records, cloud services, devices and human processes.

This chapter establishes the vocabulary and models required for later study. It explains how databases are structured, what a DBMS does, how information assets are classified, and how confidentiality, integrity and availability are protected through authentication, authorization, accountability, non-repudiation, least privilege, defence in depth and shared responsibility.

Learning Objectives

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

1. Describe database structures and distinguish a database from a DBMS.
2. Explain the main functions of a DBMS.
3. Identify information assets and assess why they require protection.
4. Use fundamental information-security terminology accurately.
5. Explain the CIA triad and relate it to practical controls.
6. Distinguish authentication, authorization, accountability and non-repudiation.
7. Apply least privilege and defence in depth to database environments.
8. Explain shared responsibility in on-premises and cloud systems.
9. Analyse a basic database-security scenario and recommend appropriate controls.

1. Database Structures

A database is an organised collection of related data designed to support storage, retrieval, updating and management. Data may be structured, semi-structured or unstructured. Structured data follows a defined model, such as rows and columns. Semi-structured data uses flexible tags or keys, as in JSON or XML. Unstructured data includes documents, images, audio and video, although metadata about these items may be stored in a structured database.

1.1 The relational model

The relational model represents data in relations, commonly displayed as tables. A table contains rows, called tuples, and columns, called attributes. For example, a Student table might contain StudentID, Name, Programme and Email. Each row represents one student, while each column represents one property of a student.

A primary key uniquely identifies each row. A foreign key is an attribute, or group of attributes, that refers to a key in another table. Foreign keys represent relationships and support referential integrity. For example, an Enrolment table may contain StudentID as a foreign key referring to Student.StudentID.

A well-designed relational database normally separates distinct subjects into different tables. This reduces duplication and prevents update anomalies. The process of organising tables to reduce inappropriate redundancy is called normalisation. At diploma level, the practical principle is that each table should represent one subject or relationship, and each non-key attribute should describe the subject identified by that table’s key. However, controlled denormalisation may be used to improve performance when its risks are understood and managed.

1.2 Schemas, instances and constraints

A schema describes the structure of a database: tables, columns, data types, relationships, views, indexes and constraints. A database instance is the actual data stored at a particular time. The schema may remain stable while the instance changes whenever records are inserted, updated or deleted.

Common constraints include:

• Domain constraints, which restrict values to appropriate types or ranges.
• NOT NULL constraints, which require a value to be present.
• Unique constraints, which prevent duplicate values in specified columns.
• Primary-key constraints, which provide row identity.
• Foreign-key constraints, which preserve valid relationships between tables.
• CHECK constraints, which enforce business rules such as a non-negative balance.

Constraints are security-relevant because they prevent invalid or maliciously manipulated data from entering the system. They do not, however, replace access control. A correctly authenticated user may still be authorized to enter a value that is valid in form but inappropriate in context.

1.3 Other database models

A hierarchical database organises records in a tree. A network database permits more complex linked relationships. Object-oriented databases store objects and their behaviour. NoSQL systems include key-value, document, column-family and graph databases. These models are often chosen for scalability, flexible schemas or particular access patterns.

Security principles apply across models, but implementation differs. A relational DBMS may use SQL roles and views, while a document database may use collection-level permissions and document filters. A graph database may require controls that prevent users from traversing sensitive relationships. Security practitioners must therefore understand both general principles and the specific controls offered by a technology.

2. What a DBMS Does

A database management system is software that defines, creates, stores, retrieves, updates and administers databases. Examples include PostgreSQL, MySQL, Microsoft SQL Server, Oracle Database and many non-relational platforms.

A DBMS commonly provides the following functions:

Data definition and manipulation

Data Definition Language (DDL) creates or changes structures such as tables and indexes. Data Manipulation Language (DML) retrieves and changes records. SQL is widely used for both purposes in relational systems. Separating structural administration from routine data access supports more precise delegation of authority.

Query processing and optimisation

The DBMS parses a query, checks its syntax and permissions, develops possible execution plans and selects an efficient plan. Indexes can reduce the amount of data that must be examined. Query optimisation improves performance, but poorly controlled queries can also expose excessive information or create denial-of-service conditions.

Transaction management

A transaction is a logical unit of work. DBMSs commonly aim to provide ACID properties:

• Atomicity: a transaction completes fully or has no effect.
• Consistency: valid constraints remain satisfied after a committed transaction.
• Isolation: concurrent transactions do not produce unacceptable interference.
• Durability: committed changes survive an appropriate system failure.

ACID properties support reliability and integrity, but they are not a complete security model. For example, an authorized administrator can commit a harmful transaction. Access controls, monitoring and governance remain necessary.

Concurrency control

Multiple users may access the same records simultaneously. Locks, timestamps, multiversion concurrency control and isolation levels help manage conflicts. The chosen isolation level involves trade-offs among consistency, throughput and latency. Security teams should ensure that concurrency settings cannot be exploited to bypass business rules or produce inconsistent security decisions.

Recovery and backup

A DBMS records sufficient information to recover from failures. Backups may be full, incremental or differential. Transaction logs can support point-in-time recovery. Backups are information assets themselves: they must be encrypted, access-controlled, tested and retained according to policy. An unprotected backup can defeat otherwise effective production security.

Metadata, views and administration

The DBMS maintains metadata about objects, users, permissions, indexes and configurations. Views present selected rows or columns without exposing the underlying tables. Administrative tools manage accounts, roles, storage, replication and auditing. Administrative interfaces should be restricted and monitored because they provide powerful capabilities.

Figure: A layered view of database access and security monitoring.

3. Information Assets and Security Terminology

An information asset is information or a resource that supports the collection, processing, storage, transmission or use of information. Assets include databases, tables, credentials, encryption keys, source code, application programming interfaces, servers, cloud storage, backups, logs, documentation and the people and processes that operate systems.

Asset owners are accountable for determining an asset’s business value, classification, retention and acceptable use. Custodians operate or protect the asset on behalf of the owner. Users access information for legitimate work. These roles should not be confused: technical administrators may maintain a database without being entitled to use all of its business content.

A threat is a potential cause of harm, such as ransomware, credential theft, fraud, human error or equipment failure. A vulnerability is a weakness that may be exploited. Risk is the possibility that a threat will exploit a vulnerability and cause an unwanted consequence. A control is a safeguard that reduces the likelihood or impact of a risk. Controls may be preventive, detective, corrective, deterrent or compensating.

Exposure is the condition of being open to a threat. An incident is an event that actually or potentially compromises confidentiality, integrity or availability. A breach generally refers to unauthorized access, disclosure, acquisition or loss of protected information, although legal definitions vary by jurisdiction. A security event is an observable occurrence; not every event is an incident.

Data classification helps match protection to sensitivity. Typical categories include public, internal, confidential and highly restricted. Classification should consider personal data, intellectual property, financial information, credentials and regulatory obligations. Classification is not permanent: information may become less sensitive after a retention period or more sensitive when combined with other data.

4. The CIA Triad

The CIA triad is a foundational model for information security.

Confidentiality

Confidentiality means preventing unauthorized disclosure of information. Database controls include strong authentication, role-based permissions, encryption in transit and at rest, data masking, secure views and careful handling of exports. Confidentiality is not absolute secrecy; authorized users and processes must be able to access information for legitimate purposes.

Integrity

Integrity means protecting the accuracy, completeness and consistency of information and processing. Controls include constraints, transaction controls, separation of duties, change management, cryptographic hashes, digital signatures, audit trails and validation. Integrity concerns both stored data and the processes that modify it.

Availability

Availability means that authorized users can access information and services when required. Redundancy, backups, disaster recovery, capacity management, patching, monitoring and denial-of-service protection contribute to availability. Availability requirements should be explicit. A payroll database may need high availability near payday, while an archive may tolerate longer restoration times.

The objectives can conflict. Encrypting data may improve confidentiality but introduce key-management dependencies that affect availability. Strict validation may protect integrity but delay urgent operations. Security design therefore balances business requirements rather than maximising one property in isolation.

5. Identity, Access and Accountability

Authentication

Authentication is the process of verifying an identity claim. Factors are commonly grouped as:

• Something the user knows, such as a password or PIN.
• Something the user has, such as a hardware token or authenticator application.
• Something the user is, such as a biometric characteristic.

Multi-factor authentication uses two or more different factor types. Two passwords are still one factor type. Passwords should be unique, protected against guessing, stored using an appropriate password-hashing scheme and never embedded in application source code. Authentication also applies to services, devices and applications, not only human users.

Authorization

Authorization determines what an authenticated subject is permitted to do. It includes actions such as SELECT, INSERT, UPDATE, DELETE, execute, administer or export. Authorization should consider the subject, resource, action, context and policy. Role-based access control assigns permissions to roles and roles to users. Attribute-based access control can use attributes such as department, location, data sensitivity and time.

Authentication answers “Who are you?” Authorization answers “What may you do?” A system can authenticate a user correctly while authorizing too much access.

Accountability

Accountability means that actions can be traced to responsible subjects and processes. Effective accountability requires unique identities, reliable timestamps, protected logs, sufficient event detail and review procedures. Shared accounts weaken accountability and should be avoided except where technically unavoidable and specially controlled. Logs must themselves be protected from alteration and unauthorized disclosure.

Non-repudiation

Non-repudiation provides evidence intended to make it difficult for a party to deny an action or communication later. Digital signatures, trusted timestamps, certificate infrastructure and protected audit trails may contribute. Non-repudiation is not produced merely by having a username in a log: the strength of the evidence depends on identity proofing, key protection, system integrity and applicable law. Organisations should avoid claiming absolute non-repudiation when controls cannot establish it.

6. Least Privilege and Separation of Duties

Least privilege means granting only the minimum permissions necessary for a subject to perform an approved task, for only as long as required. It applies to users, service accounts, applications, database administrators and automated jobs.

A practical implementation process is:

1. Identify the task and required data.
2. Define the smallest required actions.
3. Assign permissions through managed roles rather than ad hoc grants.
4. Remove inherited or unused privileges.
5. Review access regularly and after role changes.
6. Use time-limited elevation for exceptional administration.
7. Monitor and investigate privilege use.

Least privilege reduces the blast radius of stolen credentials, software defects and insider misuse. It can create operational friction if designed carelessly, so access requests should be based on documented job functions rather than convenience.

Separation of duties divides sensitive activities among people or roles. For example, one employee may request a database change, another approve it and an automated deployment process implement it. Separation of duties reduces the chance that one person can initiate and conceal harmful activity, although emergency access must be planned and audited.

7. Defence in Depth

Defence in depth uses multiple, complementary safeguards so that failure of one control does not expose the entire system. A database environment may include physical security, network segmentation, firewalls, secure configuration, identity management, application validation, database permissions, encryption, backups, monitoring and incident response.

Layers should be independent enough that a single mistake does not defeat them all. For instance, encryption does not compensate for an exposed decryption key, and network isolation does not compensate for excessive database privileges. Defence in depth also includes people and processes: training, change control, vulnerability management and tested recovery procedures.

The model should not become “security by accumulation.” Unnecessary controls increase complexity and may create misconfiguration. Each layer should have a defined purpose, owner, test method and failure response.

8. Shared Responsibility

Security responsibility is distributed among the organisation, technology providers, administrators, developers and users. In an on-premises environment, an organisation may control facilities, servers, operating systems, DBMS configuration and applications. In a cloud service, the provider may secure the physical data centre, hardware and some platform layers, while the customer remains responsible for identities, data, configurations and appropriate use.

The exact division depends on the service model and contract. Infrastructure-as-a-Service generally leaves more configuration responsibility with the customer than a managed database service. Software-as-a-Service may abstract much of the platform, but the customer still controls users, data classification, access settings and business processes.

A useful responsibility review asks:

• Who owns the data and defines its classification?
• Who manages identities and privileged access?
• Who patches the operating system and DBMS?
• Who configures network rules, encryption and backups?
• Who monitors logs and responds to incidents?
• Who tests restoration and verifies contractual commitments?

“Hosted by a provider” does not mean “secured automatically.” Misconfigured cloud storage, excessive permissions and exposed credentials remain common customer-side risks.

9. Applied Case: The Northbridge College Records Database

Background

This illustrative case concerns Northbridge College, which stores student identity information, grades, disability adjustments and payment records in a relational database. A web portal allows students and staff to access appropriate services. The database is hosted using a managed cloud database service.

Problem

A lecturer reports that a student has viewed another student’s grade record. Investigation finds that the portal uses one shared database account with broad read access. The application identifies users at the web layer but does not pass a reliable user identity to the database audit system. A nightly backup is stored in a separate cloud bucket with a permissive access policy. Logs are retained for only three days.

The incident affects confidentiality and accountability. The broad account also creates an integrity risk because the application can perform updates that are not needed for ordinary viewing.

Analysis

The college’s information assets include student records, database credentials, backups, logs and the application itself. Threats include misuse of a stolen portal credential, application flaws, accidental disclosure and unauthorized access to backups. Vulnerabilities include excessive privileges, shared identity, weak backup permissions and insufficient log retention.

The incident demonstrates the difference between authentication and authorization. The portal may have authenticated the student, but its database account was authorized to read far more data than the student should see. It also demonstrates that a backup is subject to the same confidentiality requirements as the production database.

Approach and solution

The college takes the following actions:

• Replaces the shared account with managed service identities and separate administrative accounts.
• Creates roles for students, lecturers, registry staff, finance staff and database administrators.
• Uses views and row-level restrictions so that lecturers can access only assigned classes.
• Separates read and write functions and removes unnecessary update privileges.
• Requires multi-factor authentication for staff and privileged administrators.
• Encrypts backups, restricts the backup bucket and tests restoration.
• Sends database and application audit events to protected central logging.
• Records the acting user or service identity for each sensitive operation.
• Extends retention according to legal and institutional requirements.
• Reviews access after staff transfers and at scheduled intervals.
• Performs code review and penetration testing focused on authorization failures.

Outcome

The college reduces the scope of accidental disclosure and improves its ability to investigate future events. It also discovers that availability requirements require a tested recovery plan, not merely the existence of backups. The solution is not one product: it is a combination of identity, authorization, secure design, configuration, monitoring, governance and user awareness.

Learning points

1. A database account should not be broader than the application function requires.
2. Application authentication does not automatically create database accountability.
3. Backups, logs and credentials are high-value information assets.
4. Least privilege must be applied to service accounts as well as people.
5. Controls must be tested, reviewed and connected to incident response.

10. Governance, Ethics and Contemporary Practice

Database security operates within legal, regulatory and ethical expectations. Privacy principles commonly require purpose limitation, data minimisation, accuracy, retention control, transparency and appropriate protection. Specific obligations differ by jurisdiction and sector, so professionals must consult applicable law, contracts and institutional policy rather than relying on a generic checklist.

Ethically, access should be based on legitimate need, not curiosity. Administrators with powerful privileges should respect confidentiality, avoid unnecessary inspection and use approved procedures. Monitoring should be proportionate, communicated where required and protected from misuse.

Contemporary environments increasingly use automation, cloud databases, APIs and artificial intelligence. AI systems may process sensitive training or operational data, making classification, access control and retention important. AI-generated queries or code should be reviewed because they may contain insecure assumptions, excessive permissions or data leakage. Automation should not remove human accountability for high-impact decisions.

Best practices include secure configuration baselines, patch and vulnerability management, parameterized queries to reduce injection risk, secrets management, encryption with controlled keys, tested backups, central logging, regular access reviews, incident exercises and secure disposal. Security is a continuous process because systems, threats, personnel and business purposes change.

Chapter Summary

Databases organise information for reliable storage and use, while a DBMS supplies functions such as query processing, transaction management, concurrency control, recovery, metadata management and access administration. Relational databases use tables, keys, relationships and constraints; other models use different structures but require equivalent security reasoning.

Information security protects assets against threats and vulnerabilities through controls. The CIA triad frames three central objectives: confidentiality prevents unauthorized disclosure, integrity protects correctness and completeness, and availability supports timely access by authorized users. These objectives must be balanced according to business and legal requirements.

Authentication verifies identity; authorization determines permitted actions; accountability links activity to responsible subjects; and non-repudiation provides evidence that supports attribution. Least privilege limits permissions to necessary tasks, while separation of duties reduces the concentration of power. Defence in depth combines independent technical, administrative and physical layers. Shared responsibility requires organisations and service providers to understand precisely who secures each part of a system.

Effective database security is therefore not a single feature. It is a managed system of architecture, identity, permissions, secure development, encryption, resilience, logging, governance, ethics and continuous review.

Key Terms

Database: An organised collection of related data.

Database management system (DBMS): Software that manages database structures, data, access and operations.

Schema: The defined structure and metadata of a database.

Primary key: An attribute or set of attributes that uniquely identifies a row.

Foreign key: An attribute or set of attributes that references a key in another table.

Constraint: A rule that restricts data values or relationships.

Transaction: A logical unit of database work.

Information asset: Information or a resource that supports information processing or has business value.

Threat: A potential cause of harm.

Vulnerability: A weakness that may be exploited.

Risk: The possibility of harm resulting from a threat exploiting a vulnerability.

Control: A safeguard that reduces risk.

Confidentiality: Protection against unauthorized disclosure.

Integrity: Protection of accuracy, completeness and consistency.

Availability: Timely access for authorized users.

Authentication: Verification of an identity claim.

Authorization: Determination of permitted actions.

Accountability: The ability to trace actions to responsible subjects.

Non-repudiation: Evidence supporting attribution of an action or communication.

Least privilege: Granting only the minimum necessary permissions.

Defence in depth: Use of multiple complementary security layers.

Shared responsibility: Distribution of security duties among relevant parties.

Review Questions

Short Answer Questions

1. What is the difference between a database and a DBMS?
2. Define a primary key and a foreign key.
3. What are the three elements of the CIA triad?
4. How does authentication differ from authorization?
5. Why must database backups be treated as information assets?

Long Answer Questions

1. Explain the main functions of a DBMS and discuss their relationship to security and reliability.
2. Describe the CIA triad and provide two database controls for each element.
3. Explain least privilege, separation of duties and defence in depth, showing how they complement one another.
4. Compare accountability and non-repudiation. What technical and organisational controls support each concept?
5. Explain shared responsibility in a managed cloud database environment and identify questions an organisation should ask its provider.

Analytical / Application Questions

1. A reporting application uses one database account with permission to read every table, although most users need only a small subset of records. Analyse the risks and propose a redesigned access model.
2. A company encrypts its production database but stores the encryption key and an unrestricted backup in the same cloud account. Evaluate the security weaknesses and recommend improvements.
3. An administrator claims that a username in a log proves non-repudiation. Critically assess the claim and explain what additional controls would improve attribution evidence.

Multiple Choice Questions with Answers

Question 1

Which database object uniquely identifies each row in a relational table?

A. Primary key

B. View

C. Index page

D. Foreign table

Correct Answer: A. Primary key

Question 2

Which DBMS property means that a committed transaction survives an appropriate system failure?

A. Atomicity

B. Isolation

C. Durability

D. Normalisation

Correct Answer: C. Durability

Question 3

Which activity is an example of authentication?

A. Checking whether a user may export grades

B. Verifying a user with a password and token

C. Recording a database query in a log

D. Encrypting a backup

Correct Answer: B. Verifying a user with a password and token

Question 4

Which statement best describes authorization?

A. Determining what an authenticated subject may do

B. Proving that a server has power

C. Recovering deleted records

D. Classifying a threat

Correct Answer: A. Determining what an authenticated subject may do

Question 5

A database constraint that ensures a referenced student exists primarily supports which property?

A. Confidentiality

B. Availability

C. Integrity

D. Non-repudiation

Correct Answer: C. Integrity

Question 6

Which practice best demonstrates least privilege?

A. Giving every employee database administrator access

B. Using one shared account for all applications

C. Granting a reporting service read-only access to required views

D. Keeping former employees active for convenience

Correct Answer: C. Granting a reporting service read-only access to required views

Question 7

What is the main purpose of accountability controls?

A. To make all data public

B. To trace actions to responsible subjects

C. To eliminate the need for authorization

D. To guarantee that systems never fail

Correct Answer: B. To trace actions to responsible subjects

Question 8

Which example best represents defence in depth?

A. Relying only on a firewall

B. Using network segmentation, access controls, encryption, logging and recovery controls

C. Allowing unrestricted access after authentication

D. Replacing backups with a password policy

Correct Answer: B. Using network segmentation, access controls, encryption, logging and recovery controls

Question 9

In a cloud database service, which responsibility commonly remains with the customer?

A. Manufacturing the provider’s physical servers

B. Managing the provider’s building security

C. Configuring customer identities, permissions and data

D. Repairing the provider’s power infrastructure

Correct Answer: C. Configuring customer identities, permissions and data

Question 10

Why are shared database accounts a security weakness?

A. They always reduce storage capacity

B. They make individual accountability and precise privilege management difficult

C. They prevent all transactions from committing

D. They automatically encrypt data incorrectly

Correct Answer: B. They make individual accountability and precise privilege management difficult