Security, Privacy, Ethics, and Governance

Introduction

Database applications are trusted with identities, financial records, health information, business transactions, intellectual property, and behavioural data. A database that is technically functional but poorly protected can expose an organisation to fraud, operational disruption, legal penalties, reputational damage, and harm to individuals. Security and governance are therefore not optional additions to database development; they are design responsibilities.

This chapter examines the practical foundations of protecting MySQL and MongoDB systems. It focuses on authentication, authorization, least privilege, encryption, secrets management, auditing, backups, retention, privacy, ethical data use, regulatory awareness, and protection against SQL and NoSQL injection. The central principle is that database protection requires several mutually reinforcing controls. Encryption cannot compensate for excessive privileges; authentication cannot compensate for insecure application queries; and backups are not useful if they cannot be restored securely.

Learning Objectives

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

• distinguish authentication, authorization, accounting, and auditing;
• design database accounts and roles according to least privilege;
• explain encryption in transit, encryption at rest, hashing, and key management;
• manage credentials and connection secrets safely;
• construct basic audit, backup, recovery, retention, and incident-response policies;
• apply privacy and ethical principles to database projects;
• recognise regulatory responsibilities without treating compliance as a substitute for security;
• prevent SQL injection and NoSQL injection through safe query construction and validation;
• evaluate a database security design using professional risk-based reasoning.

1. A Security Model for Database Systems

Database security is commonly described using the CIA triad:

• Confidentiality means that information is disclosed only to authorised people and systems.
• Integrity means that information remains accurate, complete, and protected from unauthorised alteration.
• Availability means that authorised users can access required information when needed.

These goals interact. For example, encrypting every database file may strengthen confidentiality but can reduce availability if keys are lost. Strict access controls may protect integrity but can impede legitimate work if permissions are designed too narrowly. Professional security therefore balances risk, usability, cost, and legal obligations.

A useful operational model is the AAA model:

1. Authentication verifies who or what is requesting access.
2. Authorization determines what the authenticated identity may do.
3. Accounting or auditing records relevant activity for investigation, assurance, and accountability.

Authentication is not authorization. A valid employee account does not automatically justify access to every table. Similarly, a log is not a preventive control: auditing can reveal misuse, but it does not itself prevent the action.

Threats and attack surfaces

A database may be attacked through:

• application forms and APIs;
• stolen passwords, tokens, or connection strings;
• excessive database privileges;
• insecure backups and exports;
• unpatched database servers and drivers;
• malicious insiders or compromised administrators;
• cloud configuration errors;
• injection attacks;
• ransomware or destructive commands;
• accidental disclosure through logs, reports, or test data.

Security analysis should identify assets, actors, entry points, vulnerabilities, likely impacts, and available controls. A small student project may not need the same controls as a hospital system, but every project should demonstrate deliberate decisions rather than relying on default settings.

2. Authentication and Authorization

Authentication

Authentication mechanisms include passwords, certificates, hardware security keys, one-time codes, and federated identity systems. Passwords should be long, unique, and stored by applications only as slow, salted password hashes. A password hash is not encryption: hashing is intended to be one-way, whereas encryption is designed for reversible recovery using a key.

Applications should avoid implementing password storage algorithms themselves. Established password-hashing schemes such as Argon2id, bcrypt, or scrypt should be configured according to current organisational guidance. Passwords must never be stored in plaintext, reversible encryption, source code, SQL scripts, or ordinary log files.

Multi-factor authentication (MFA) combines different factor types, such as:

• something the user knows, such as a password;
• something the user has, such as a security key or authenticator device;
• something the user is, such as a biometric characteristic.

Two passwords are not two independent factors. MFA is particularly important for administrators, remote access, cloud consoles, and systems containing sensitive personal data.

Database identities and service accounts

A production application should normally use a dedicated service account rather than a personal administrator account. Each service should have its own identity so that permissions can be limited and actions can be attributed. Shared accounts weaken accountability and make it difficult to revoke one person’s access without disrupting others.

MySQL and MongoDB both support database users and roles, although their syntax and operational details differ by version and deployment mode. Administrators should consult the version-specific documentation and avoid assuming that a setting available in one product exists identically in the other.

Authorization and role-based access control

Authorization can be implemented through:

• Role-based access control (RBAC): permissions are assigned to roles, and users receive roles.
• Attribute-based access control (ABAC): decisions consider attributes such as department, location, device status, record classification, or time.
• Row- or document-level controls: access is restricted to particular records or documents rather than an entire table or collection.

RBAC is often a practical starting point for diploma-level applications. Typical roles may include application_reader, application_writer, reporting_user, and database_admin. A reporting user should not automatically be able to update operational records.

Least privilege

Least privilege means granting only the permissions necessary for a defined task, for only as long as they are needed. It applies to people, applications, jobs, containers, and database administrators.

For example, an application that displays product information may need SELECT on selected columns or views, but not permission to drop tables, create users, or read payroll data. A migration account may require schema modification privileges temporarily, while the ordinary runtime account should not retain them.

A practical permission-review process is:

1. list the operation required by each component;
2. identify the exact tables, collections, views, or procedures involved;
3. grant the smallest suitable permission;
4. test expected operations and rejected operations;
5. review permissions periodically and after system changes;
6. remove unused accounts and privileges.

Denying access by default is safer than granting broad access and attempting to discover misuse later.

3. Secure Query Construction and Injection Prevention

SQL injection

SQL injection occurs when untrusted input changes the structure or meaning of a SQL statement. A vulnerable pattern concatenates input into a query:

query = "SELECT * FROM users WHERE email = '" + email + "'"

An attacker may submit specially crafted text that terminates the intended string and adds another condition or command. The precise effect depends on the database, driver, permissions, and query context.

The primary defence is a parameterized query, also called a prepared statement:

SELECT id, email FROM users WHERE email = ?

The value of email is supplied separately through the database driver. The driver treats it as data rather than executable SQL. Parameterization should be used for values in WHERE, INSERT, UPDATE, and DELETE operations.

Allow-list validation is required for structural elements that cannot normally be parameterized, such as a selected sort column or a table name. The application should map a small set of approved external names to fixed internal SQL fragments. Escaping alone is a weaker and more error-prone defence, especially when character encodings or query contexts vary.

Additional controls include:

• input validation based on business rules;
• restricted database privileges;
• safe error messages that do not reveal schema details;
• secure database drivers and patched dependencies;
• code review and automated security testing;
• monitoring for unusual query patterns.

NoSQL injection

NoSQL databases are not automatically immune to injection. In MongoDB applications, a vulnerability may occur when user-controlled objects are accepted as query operators. For example, an application expecting a string username may accidentally accept an object containing an operator such as $ne, causing the query to match unintended documents.

Defences include:

• validate input types, not merely field names;
• accept only the fields and operators required by the API;
• reject keys beginning with $ or containing prohibited path patterns where appropriate;
• construct query objects explicitly rather than passing request bodies directly to the database;
• use framework and driver protections against operator injection;
• apply authorization checks independently of query results;
• limit returned fields and result sizes.

A safe conceptual pattern is:

username = validateString(request.body.username)
filter = { username: username }
document = users.findOne(filter, { projection: { passwordHash: 0 } })

The application should not simply execute findOne(request.body) unless the input has been rigorously constrained and the design explicitly permits that behaviour.

Injection testing should include malicious strings, unexpected arrays and objects, null values, very long inputs, encoded characters, and attempts to introduce operators. Security testing must occur in an isolated environment using non-production data.

4. Encryption, Hashing, and Secrets Management

Encryption in transit

Encryption in transit protects data moving between an application, database server, administrator workstation, replica, or backup service. Transport Layer Security (TLS) can provide confidentiality, integrity, and server authentication when certificates are validated correctly.

A secure deployment should:

• require encrypted connections for sensitive traffic;
• validate certificates and hostnames;
• disable obsolete protocols and weak cipher configurations according to current guidance;
• protect internal replication and administrative connections where supported;
• monitor certificate expiry.

Simply enabling a TLS option without certificate validation can permit man-in-the-middle attacks.

Encryption at rest

Encryption at rest protects database files, disks, snapshots, and backups if storage media are stolen or improperly accessed. It does not protect data from an authenticated application account that is already authorised to read it. Database-level, filesystem-level, and cloud-storage encryption may be combined, but key access must be separated from ordinary database access where practical.

Hashing and tokenization

Sensitive values should be handled according to their use:

• passwords require salted, slow password hashing;
• data that must be recovered requires encryption;
• data used only for matching may sometimes use a keyed hash, subject to the risk of guessing attacks;
• payment-card or identity data may require tokenization or specialised controls.

Hashing a low-entropy value, such as a short PIN, does not make it safe if attackers can guess values and compare hashes. Confidentiality design must consider the likely attack space, not merely the presence of a cryptographic function.

Secrets management

Database passwords, API keys, encryption keys, certificates, and connection strings are secrets. They should not be committed to source control, embedded in mobile applications, placed in client-side JavaScript, or printed in logs.

A secrets-management service or protected deployment mechanism should provide controlled storage, access policies, auditing, rotation, and—where possible—short-lived credentials. Applications should receive only the secrets they require. Rotation must be designed so that old and new credentials can overlap safely during deployment.

Developers should scan repositories and build artifacts for accidental secrets. If a secret is exposed, deleting the file is insufficient: the secret must be revoked or rotated, and the exposure should be investigated.

5. Auditing, Monitoring, and Accountability

Auditing records significant events such as successful and failed logins, privilege changes, schema changes, sensitive reads, exports, administrative actions, and backup or restore operations. Logs should support the questions: who acted, what occurred, when it occurred, where it originated, and whether it succeeded.

Audit design must balance usefulness and privacy. Collecting every possible field can create a second sensitive database. Logs should be protected from unauthorised alteration, retained for a defined period, and monitored for suspicious patterns. Time should be synchronised across systems so that events can be correlated.

Examples of warning signals include:

• repeated failed authentication;
• access from unusual locations or times;
• sudden bulk reads or exports;
• privilege escalation;
• queries that differ sharply from normal application behaviour;
• deletion or alteration of audit records;
• disabled logging or unexpected configuration changes.

A log is useful only if someone or something reviews it. Organisations should define alert thresholds, escalation contacts, evidence-preservation procedures, and responsibilities for investigation.

6. Backup, Recovery, and Business Continuity

Backups support availability and integrity, but a backup system itself contains valuable data and must be protected. A sound policy specifies:

• what is backed up;
• backup frequency and retention;
• storage location and geographic separation;
• encryption and key management;
• access permissions;
• integrity verification;
• restore testing;
• recovery priorities and responsibilities.

Important measures include:

• Recovery Point Objective (RPO): the maximum acceptable amount of data loss, expressed as time. An RPO of one hour means the organisation aims to lose no more than approximately one hour of changes after an incident.
• Recovery Time Objective (RTO): the maximum acceptable time to restore service after disruption.

RPO and RTO are business requirements, not merely database settings. A system requiring a five-minute RPO may need frequent incremental capture or replication, whereas a small internal tool may accept daily backups.

Backups should follow a version of the 3-2-1 principle: maintain at least three copies, on at least two types of storage, with at least one copy isolated or off-site. The exact implementation may vary, but the principle reduces the risk that one failure or ransomware event destroys every copy.

A restore test should verify more than file existence. It should restore into an isolated environment, validate schema and data integrity, test application connectivity, confirm permissions, measure recovery time, and document deficiencies. A backup that has never been restored is an assumption, not proven recovery capability.

7. Data Retention and Secure Disposal

Data should be retained for a defined business, legal, or operational purpose and deleted when that purpose expires, subject to applicable preservation duties. Indefinite retention increases the impact of a breach and can conflict with privacy principles.

A retention schedule should identify:

Deletion must consider replicas, caches, exports, reports, audit records, and backups. In some contexts, legal or security audit records may need to be retained even when operational data is deleted; policies should explain these distinctions. Anonymisation should be assessed carefully because combinations of supposedly harmless fields may re-identify individuals.

8. Privacy, Ethics, and Regulatory Awareness

Privacy is concerned with appropriate control over information about identifiable or identifiable individuals. Security protects information from unauthorised access and misuse; privacy also asks whether collection, use, sharing, and retention are justified in the first place.

Important privacy principles found in many legal frameworks include:

• lawfulness, fairness, and transparency;
• purpose limitation;
• data minimisation;
• accuracy;
• storage limitation;
• confidentiality and integrity;
• accountability.

Regulatory requirements differ by jurisdiction and sector. Examples include the European Union General Data Protection Regulation, the United Kingdom data-protection regime, state or national privacy laws, health-information rules, financial regulations, and breach-notification requirements. A developer must not assume that a system is compliant merely because it uses encryption. Compliance depends on facts such as location, individuals affected, processing purpose, contracts, sector, transfers, and organisational responsibilities. Legal advice may be necessary.

Privacy by design embeds privacy controls throughout the development lifecycle. Practical measures include:

• identifying personal and sensitive data before implementation;
• documenting the purpose of each field;
• collecting the minimum necessary attributes;
• using pseudonymous identifiers where feasible;
• separating identity data from operational data;
• restricting access by role and purpose;
• providing correction and access processes where legally required;
• assessing third-party processors and data transfers;
• conducting a privacy impact assessment for high-risk processing.

Ethical data use goes beyond legal compliance. A database project may be legal but still unfair, invasive, deceptive, or harmful. Ethical review should ask:

• Would affected people reasonably expect this collection and use?
• Could the data create discrimination or exclusion?
• Are consent and notices understandable rather than hidden in technical language?
• Could an error cause serious harm?
• Is there a human review or appeal path for consequential decisions?
• Are vulnerable groups disproportionately affected?

Automated decisions and AI systems require particular care. Training or inference data may contain bias, inaccurate labels, historical discrimination, or sensitive attributes. Access to a database does not create an ethical entitlement to use its contents for a new purpose. Data provenance, quality, model documentation, human oversight, and testing for disparate impacts are important governance controls.

9. Governance and Secure Development

Governance establishes who makes decisions, who is accountable, which policies apply, and how compliance is demonstrated. A practical database governance programme includes:

• data ownership and custodianship;
• data classification;
• access approval and periodic review;
• change management;
• vulnerability and patch management;
• incident response;
• vendor and cloud assessment;
• retention and disposal schedules;
• documented recovery objectives;
• security training.

Security should be integrated into the software development lifecycle. During design, identify threats and data flows. During implementation, use parameterized queries and secure libraries. During testing, test authorization boundaries, injection resistance, backup restoration, and logging. During deployment, harden configurations and remove development credentials. During operation, patch, monitor, review, and improve.

A useful governance distinction is between policy, standard, procedure, and evidence. A policy states an organisational requirement; a standard defines a mandatory technical baseline; a procedure explains how work is performed; evidence demonstrates that the requirement was followed. For example, “sensitive databases must use encrypted connections” is a policy statement, while a documented TLS configuration and connection test provide evidence.

10. Illustrative Case: Student Services Database

Background

A college operates a student-services application using MySQL for enrolment and billing. MongoDB stores support conversations and uploaded service metadata. The original application uses one database administrator account, stores a connection password in source control, concatenates search terms into SQL, and passes request filters directly to MongoDB. Backups run nightly but have never been restored in testing.

Problem

A support worker reports seeing records from another department. Security staff also identify a public repository containing the database password. The system has no documented retention schedule, and support conversations contain unnecessary identity details.

Analysis

The design has multiple independent weaknesses. Shared administrative access violates least privilege and weakens accountability. The exposed password may permit unauthorised access even if no attack has yet been detected. SQL concatenation creates injection risk, while unrestricted MongoDB filters create NoSQL operator-injection risk. Lack of restore testing leaves availability uncertain. Excessive conversation data creates privacy risk and increases the consequences of disclosure.

Approach and solution

The college first disables and rotates the exposed credential, reviews access logs, and investigates whether it was used. It creates separate accounts for the application, reporting, migrations, and administration. The runtime account receives only the permissions needed for ordinary operations.

The development team replaces SQL string concatenation with prepared statements. It builds MongoDB filters from explicitly validated fields and rejects unexpected objects and operators. The API also performs department-level authorization checks rather than assuming that a database filter alone is sufficient.

TLS is required for application and administrative connections. Secrets move to a managed secret store, and repository scanning is added to the development pipeline. Sensitive fields are removed from routine logs, and audit events are sent to protected central storage.

The college defines RPO and RTO values with service owners, creates encrypted and access-controlled backups, and performs a documented restore test. A retention schedule removes unnecessary support details and defines controlled deletion of old records and exports. Staff receive training on privacy, phishing, and reporting suspected incidents.

Outcome

The revised design reduces the likelihood and impact of credential compromise, injection, unauthorised access, and accidental disclosure. The college can demonstrate who approved access, how records are retained, and whether recovery works. It has not eliminated all risk, but it has converted undocumented assumptions into testable controls.

Learning points

1. A security incident may result from several small weaknesses acting together.
2. Authorization must be enforced at the application and data layers where appropriate.
3. Secret rotation and incident investigation are required after exposure.
4. Backup success is not equivalent to recovery success.
5. Privacy improvement often begins by collecting less data.

11. Challenges and Limitations

No security control is perfect. Strong MFA may be difficult for users with limited access to devices. Encryption can complicate searching, indexing, key recovery, and performance. Detailed auditing can create privacy risks and storage costs. Least privilege can slow development if permission requests are poorly managed. Anonymisation may fail when external datasets permit re-identification. Automated anomaly detection can produce false positives, while attackers may remain below alert thresholds.

Security also depends on configuration and operations. A well-designed policy may fail when credentials are shared, patches are delayed, backups are not tested, or administrators bypass controls. Consequently, security assurance should combine technical controls, documented processes, staff competence, independent review, and continuous improvement.

Best-Practice Checklist

Before releasing a MySQL or MongoDB application, verify that:

• authentication is strong and administrator access uses MFA where feasible;
• service accounts are separate, named, and least-privileged;
• authorization is tested for both allowed and denied operations;
• SQL uses prepared statements and dynamic identifiers use allow-lists;
• NoSQL input is type-validated and operators are controlled;
• TLS and certificate validation protect sensitive connections;
• data at rest and backups have appropriate encryption and key controls;
• secrets are outside source code and can be rotated;
• audit logs are protected, reviewed, and privacy-aware;
• backups are encrypted and restoration is tested;
• RPO, RTO, retention, and disposal responsibilities are documented;
• personal data collection has a clear purpose and is minimised;
• incident response and breach-escalation procedures are known;
• dependencies, drivers, database versions, and configurations are maintained.

Chapter Summary

Database security is a layered discipline covering confidentiality, integrity, and availability. Authentication establishes identity, authorization limits permitted actions, and auditing supports accountability. Least privilege, dedicated service accounts, role-based access, and periodic reviews reduce the damage caused by misuse or compromise.

Parameterized SQL prevents data from being interpreted as executable SQL, while NoSQL applications must validate types and explicitly construct query objects to prevent operator injection. TLS protects data in transit; encryption at rest protects storage; hashing is appropriate for passwords; and secrets require controlled storage and rotation.

Reliable governance includes protected audit records, tested backups, defined RPO and RTO values, retention schedules, secure disposal, incident response, and change management. Privacy requires purpose limitation, minimisation, transparency, accuracy, and accountability. Ethical practice asks whether data use is fair, expected, proportionate, and harmful to vulnerable groups. Regulatory awareness is essential, but compliance does not replace sound engineering and responsible judgement.

Key Terms

Authentication: Verification of an identity.

Authorization: Determination of what an authenticated identity may do.

Least privilege: Granting only the permissions necessary for a task.

Role-based access control: Assigning permissions to roles and assigning users to those roles.

Multi-factor authentication: Authentication using two or more independent factor types.

Encryption: Reversible transformation of data using a key to protect confidentiality.

Hashing: One-way transformation commonly used for password verification and integrity operations.

Salt: Random value combined with a password before hashing to reduce precomputed attacks.

TLS: Protocol family that protects network communication and authenticates endpoints through certificates.

Secret: Confidential credential, key, token, certificate, or connection value.

SQL injection: Manipulation of SQL through untrusted input incorporated into a query.

NoSQL injection: Manipulation of a NoSQL query or operator structure through untrusted input.

Audit trail: Protected record of relevant system and user activity.

RPO: Maximum acceptable period of data loss after a disruption.

RTO: Maximum acceptable time to restore a service.

Data minimisation: Collecting and retaining only data necessary for a defined purpose.

Pseudonymisation: Processing data so direct identification is separated from the data, while re-identification may remain possible.

Data retention: Controlled period for which data is kept.

Governance: Structures, policies, responsibilities, and evidence used to direct and control data management.

Privacy by design: Integrating privacy protections throughout system design and operation.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization.
2. Why should an application runtime account not normally be a database administrator?
3. What is the main purpose of a parameterized SQL query?
4. Define RPO and RTO.
5. State two principles of privacy-aware data collection.

Long Answer Questions

1. Explain how least privilege, RBAC, auditing, and periodic access review work together in a database environment.
2. Compare encryption, password hashing, and tokenization, including an appropriate use for each.
3. Describe a secure backup and restoration policy for a system containing personal data.
4. Explain the causes and prevention of SQL injection and NoSQL injection.
5. Discuss why legal compliance alone is insufficient for ethical database governance.

Analytical / Application Questions

1. An API passes a complete JSON request body directly to a MongoDB findOne operation. Analyse the risks and propose a safer design.
2. A company can tolerate at most four hours of data loss and requires service restoration within two hours. Identify its RPO and RTO requirements and recommend controls that should be tested.
3. A college wants to retain all student support conversations indefinitely “for future analytics.” Evaluate this proposal using privacy, ethical, security, and governance principles, and recommend an alternative policy.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorization?

A. Authentication determines permissions, while authorization verifies identity.

B. Authentication verifies identity, while authorization determines permitted actions.

C. Authentication encrypts data, while authorization backs it up.

D. Authentication records events, while authorization deletes logs.

Correct Answer: B. Authentication verifies identity, while authorization determines permitted actions.

Question 2

What is the primary purpose of a parameterized SQL query?

A. To make every database user an administrator

B. To store passwords in reversible form

C. To separate untrusted values from SQL command structure

D. To eliminate the need for authorization

Correct Answer: C. To separate untrusted values from SQL command structure

Question 3

Which practice best demonstrates least privilege?

A. Giving every developer full database administration rights

B. Using one shared account for all services

C. Granting an application only the operations and data it requires

D. Allowing users to select their own permissions

Correct Answer: C. Granting an application only the operations and data it requires

Question 4

Which control is most directly associated with protecting data in transit?

A. TLS with certificate validation

B. A retention schedule

C. A database index

D. A restore test

Correct Answer: A. TLS with certificate validation

Question 5

Why is a password hash generally preferable to encryption for storing passwords?

A. A hash is intended to be one-way, so the original password need not be recovered.

B. A hash allows administrators to read every password.

C. Encryption cannot use keys.

D. Hashing automatically provides multi-factor authentication.

Correct Answer: A. A hash is intended to be one-way, so the original password need not be recovered.

Question 6

An organisation can accept losing no more than one hour of recent changes after a disaster. Which requirement does this describe?

A. An RTO of one hour

B. An RPO of one hour

C. A TLS interval of one hour

D. A retention period of one hour

Correct Answer: B. An RPO of one hour

Question 7

Which situation creates a NoSQL injection risk?

A. A validated string is placed into an explicitly constructed filter

B. A request body is accepted as an unrestricted MongoDB query object

C. A backup is stored in an encrypted repository

D. A database user is assigned a reporting role

Correct Answer: B. A request body is accepted as an unrestricted MongoDB query object

Question 8

Which privacy principle supports collecting only fields necessary for a stated purpose?

A. Data minimisation

B. Privilege escalation

C. Replication

D. Certificate pinning

Correct Answer: A. Data minimisation

Question 9

Why should database backups be restored in testing?

A. To prove that files exist and recovery actually works

B. To increase the permissions of the backup account

C. To remove the need for audit logs

D. To convert hashes into plaintext passwords

Correct Answer: A. To prove that files exist and recovery actually works

Question 10

What should normally happen after a database credential is exposed in a public repository?

A. Rename the source-code file only

B. Ignore it unless an attack is confirmed

C. Rotate or revoke the credential and investigate possible use

D. Print the credential in application logs for comparison

Correct Answer: C. Rotate or revoke the credential and investigate possible use