COMP 6660 · Enterprise Cybersecurity Database Security

00 Introduction

Lesson 5.3 examined application security — the software that delivers enterprise services. This lesson examines database security — the discipline of protecting the data stores on which applications depend, and which hold the enterprise's most sensitive information.

Databases are the destination. Applications process data; users interact with data through applications; but the data itself resides in databases and data stores. When an adversary accesses a database, they gain access to the data — customer records, financial information, intellectual property, personal data, and everything else the enterprise holds. Many of the most consequential breaches have been, at their core, database breaches — unauthorized access to the enterprise's data.

Database security is a distinct discipline because databases present distinct security considerations. Databases have their own access-control models — separate from application and operating-system access control. Databases store data in specific ways that require specific encryption approaches. Databases generate specific logs and audit trails that support detection and investigation. Databases interact with applications, with users, with other systems, and with cloud services — through interfaces that each require protection. And databases frequently hold data that is subject to specific regulatory requirements, which shape the controls that must be applied.

This lesson examines database security in detail. It establishes why database security matters. It examines the database attack surface — the interfaces, components, and data that databases expose. It examines database access control — the models through which access to data is governed. It examines encryption — protecting data at rest, in transit, and in use. It examines auditing and monitoring — detecting what happens in databases. It examines data masking and privacy controls — protecting sensitive data within databases. It examines database hardening and configuration. It examines backup, recovery, and integrity. It examines the specific considerations of cloud databases and data services. And it closes with the pitfalls that recur across database security programmes.

The material here builds on the application security material from Lesson 5.3 — applications and databases are closely coupled, and the security of one affects the other. It connects to the data-protection material from Module 1 — encryption, access control, and classification. It prepares for the cloud security material in Lesson 5.5, where managed database services and cloud data stores are examined in the context of the shared responsibility model.

01 Learning objectives

By the end of this lesson you should be able to:

These objectives contribute to Unit 5 outcome U5.1 (secure infrastructure), and to Module 2 outcome M2.8. See the Unit 5 learning outcomes page for the full mapping.

02 Why database security matters

Databases hold the enterprise's most valuable asset — its data. They are the destination that adversaries seek and the object that regulation protects. Understanding why database security matters clarifies the priorities that inform the rest of this lesson.

The consequence of database security failures

Database security failures appear across documented breaches:

• Direct database compromise. Adversaries who access databases directly — through stolen credentials, through exploitation, through misconfiguration — extract the data they seek.
• Application-mediated database access. Adversaries who compromise applications frequently use the application's database access to extract data — bypassing database access controls that permit the application.
• Cloud database misconfiguration. Cloud databases misconfigured for public access have been the source of substantial data exposure — a recurring pattern in cloud incidents.
• Excessive database privileges. Applications, users, and services with excessive database privileges — permitting access to data they do not need.
• Unencrypted databases. Databases without encryption — permitting access to data if backups, storage, or snapshots are compromised.

The pattern is consistent: database security failures permit access to the enterprise's most valuable data. Database security is essential — infrastructure, platform, and application security alone are insufficient without controls that protect the data itself.

03 The database attack surface

Databases present a specific attack surface — interfaces, components, and data through which databases can be attacked. Understanding the attack surface informs both the controls that databases require and the specific vulnerabilities that database security addresses.

Components of the database attack surface

Categories of database attack

Attacks against databases fall into several categories:

Reducing the database attack surface

The foundational principle of database security is to reduce the attack surface to what the database requires:

• Minimise exposure. Databases should not be exposed beyond what they require — network exposure should be limited to authorized clients; management interfaces should not be internet-facing.
• Minimise accounts. Database accounts should be minimised — each account should exist for a specific purpose and be removed when no longer needed.
• Minimise privileges. Each database account should have only the privileges it requires — least privilege applied to database access.
• Minimise data. Databases should hold only the data they require — data minimisation reduces the consequence of compromise.
• Minimise functionality. Unnecessary database features — stored procedures, integrations, extensions — should be disabled or removed.
• Minimise integrations. Database integrations should be limited to what is required — each integration is a potential attack path.

04 Database access control

Database access control is the discipline of determining which accounts can access which data — and what they can do with it. It is the primary control protecting the data within the database.

Database access control models

Database accounts and privileges

Database access control centres on accounts and privileges:

Application account security

Application accounts — the accounts applications use to access databases — are particularly important. They are frequently over-privileged and frequently the source of database compromise:

• Least privilege. Application accounts should have only the privileges the application requires — not administrative privileges, not access to tables the application does not use.
• Separate accounts per application. Each application should have its own database account — not shared accounts across applications. Separate accounts limit the consequence of compromise.
• Credential management. Application account credentials should be managed securely — vaulted, rotated, and not hard-coded in application code or configuration.
• Network restrictions. Application accounts should be restricted to the specific hosts or networks from which the application connects — limiting the exposure if credentials are compromised.
• Monitoring. Application account activity should be monitored — detecting anomalies that may indicate compromise of the application or the account.

Database access control in practice

Implementing database access control involves several activities:

• Inventory accounts. Identify every database account — administrative, application, service, user, and default. This is the foundation — without an accurate inventory, access control is not possible.
• Reduce privileges. Remove excessive privileges — from application accounts, from service accounts, from administrative accounts. Apply least privilege systematically.
• Eliminate shared accounts. Replace shared accounts with dedicated accounts — for each application, each service, and each administrator. Shared accounts eliminate accountability.
• Disable default accounts. Disable or remove default database accounts — the accounts that come with the database platform and are frequently the source of compromise.
• Restrict network access. Restrict database network access — through firewalls, through listener configuration, through network policy — so that only authorized clients can reach the database.
• Manage credentials. Manage database credentials — through password management, through vaulting, through rotation. Avoid hard-coded credentials.
• Review access. Review database accounts and privileges periodically — removing accounts and privileges that are no longer needed.

05 Encryption

Database encryption is the use of cryptography to protect data in the database — protecting it from unauthorized access if the database, its storage, or its backups are compromised. Encryption is one of the strongest controls in database security — providing protection that persists even when other controls fail.

Encryption states

Key management for database encryption

Encryption is only as strong as its key management. Database encryption requires specific key management considerations:

• Key generation. Encryption keys should be generated using cryptographically secure random number generators — not derived from passwords or other predictable sources.
• Key storage. Keys should be stored securely — in hardware security modules (HSMs), in key management services, or in database-native key management. Keys stored in files, in configuration, or in application code are vulnerable.
• Key access. Access to encryption keys should be restricted — limited to the systems and processes that require them. Access should be logged and audited.
• Key rotation. Encryption keys should be rotated periodically — limiting the consequence of key compromise. Rotation requires re-encryption of the protected data — a substantial operational effort for large databases.
• Key separation. Different encryption purposes should use different keys — separate keys for encryption at rest, for encryption in transit, and for other cryptographic purposes.
• Key backup and recovery. Keys should be backed up — but the backup itself must be protected. Loss of encryption keys means loss of the encrypted data.
• Key destruction. Keys should be destroyed when no longer needed — cryptographic erasure of the data they protected.

Cloud key management

Cloud databases introduce specific key management considerations:

• Provider-managed keys. The cloud provider manages the encryption keys — simplest to use, but the enterprise has limited control and limited visibility.
• Customer-managed keys. The enterprise manages the encryption keys — typically through the provider's key management service. Provides greater control and auditability.
• Customer-provided keys. The enterprise provides the encryption keys — through hardware security modules or through the provider's key import mechanisms. Provides the greatest control but requires the most operational effort.
• BYOK (Bring Your Own Key). The enterprise brings its own keys to the cloud provider's key management service — providing control over key lifecycle while leveraging the provider's infrastructure.
• HYOK (Hold Your Own Key). The enterprise holds its own keys outside the cloud provider — providing the strongest control but the most operational complexity.

06 Auditing and monitoring

Database auditing and monitoring is the discipline of recording and analysing database activity — detecting misuse, supporting investigation, and demonstrating compliance. It is the detection counterpart of database access control and encryption.

What database auditing provides

• Activity records. Records of what happened in the database — who accessed what data, what they did with it, and when.
• Compliance evidence. Evidence that the enterprise's controls are operating — supporting compliance with regulatory requirements (PCI DSS, HIPAA, GDPR, and others).
• Detection capability. Detection of suspicious database activity — unauthorized access, privilege escalation, data exfiltration, and other indicators of compromise.
• Investigation support. Records that support investigation of incidents — reconstructing what happened and identifying affected data.
• Accountability. The record through which database activity can be attributed to specific accounts — supporting accountability and deterrence.

What to audit

Database auditing approaches

Audit log protection

Audit logs are targeted by adversaries — to cover their tracks, to disable monitoring, to conceal their activity. Protecting audit logs is essential:

• Centralise logs. Send audit logs to a central location — through a SIEM, through a dedicated log platform — so that they are not lost if the database is compromised.
• Protect log integrity. Use mechanisms that detect tampering — through hashing, through blockchain-based logging, through write-once storage.
• Separate log access. Access to audit logs should be restricted — not available to database administrators whose activity is being audited.
• Retain logs. Audit logs should be retained for sufficient periods — to support investigation and compliance. Retention requirements vary by regulation.
• Monitor logs. Audit logs should be monitored — not just collected. Monitoring detects the activity the auditing is intended to capture.

Database activity monitoring in practice

Effective database monitoring involves several activities:

• Define what to monitor. Not everything needs to be monitored — focusing on sensitive data, privileged activity, and anomalous patterns.
• Configure auditing appropriately. Configure native auditing to capture the events that matter — without producing overwhelming log volume.
• Deploy DAM where needed. Deploy database activity monitoring for the most sensitive databases — providing the visibility that native auditing cannot.
• Integrate with SIEM. Feed database logs into the enterprise's SIEM — providing correlation and centralised monitoring.
• Monitor for anomalies. Monitor for behavioural anomalies — unusual access, unusual volumes, unusual times — that may indicate compromise or misuse.
• Investigate alerts. Investigate suspicious activity — through the investigation tools and processes of the SOC.
• Review regularly. Review database activity periodically — identifying patterns, identifying anomalies, refining monitoring.

07 Data masking and privacy controls

Data masking and related privacy controls reduce the exposure of sensitive data within databases — by replacing sensitive values with substitutes that preserve the data's usefulness for specific purposes while protecting its confidentiality.

Privacy control approaches

Data masking use cases

• Development and testing. Developers and testers need realistic data — but not the actual sensitive data. Masked copies provide realistic data without exposing sensitive information.
• Analytics and reporting. Analysts need data for analytics — but may not need (or be authorized to see) the specific identities involved. Masked or pseudonymised data supports analytics without exposing identities.
• Third-party data sharing. Sharing data with third parties — partners, vendors, researchers — may require masking to protect sensitive information while providing useful data.
• Regulatory compliance. Privacy regulation frequently requires that data be minimised, pseudonymised, or anonymised in specific contexts.
• Production data access. Some users may need access to production data but not to the most sensitive elements. Dynamic masking provides access with protection.

Data minimisation

Beyond masking, data minimisation is a fundamental privacy principle — reducing the volume of sensitive data the enterprise holds:

• Collect only what is needed. Data collection should be limited to what is genuinely required for the stated purpose.
• Retain only as long as needed. Data retention should be limited — data should be disposed of when it is no longer needed for its purpose.
• Aggregate where possible. Aggregate data — summary statistics, grouped data — is less sensitive than the underlying individual records.
• Separate sensitive data. Separating sensitive data from other data reduces the scope of protection required and the consequence of compromise.
• Dispose of data securely. Data disposal should be secure — through cryptographic erasure, through secure deletion, through verified media destruction.

08 Database hardening and configuration

Database hardening applies the OS and application hardening principles from Lessons 5.1 and 5.3 to the database platform. The principles are the same — reduce the attack surface, apply secure configuration, reduce privilege, patch promptly — but the implementation adapts to the specific characteristics of database platforms.

Database hardening dimensions

Database hardening benchmarks

Database hardening is informed by published benchmarks and guidance:

• CIS Benchmarks for databases. CIS publishes detailed hardening guidance for Oracle, SQL Server, MySQL, PostgreSQL, MongoDB, and other database platforms.
• Vendor hardening guides. Database vendors publish their own hardening guidance — tailored to their platforms.
• STIGs. DISA publishes Security Technical Implementation Guides for database platforms — strict and prescriptive.
• NIST guidance. NIST publishes database security guidance and checklists.
• Sector-specific benchmarks. PCI DSS, HIPAA, and other sector-specific frameworks include database security requirements.

Database hardening implementation

• Role-based baselines. Different databases serve different functions — production, development, analytics, data warehouse. Each requires a baseline appropriate to its role.
• Automated deployment. Baselines should be deployed automatically — through configuration management, through database automation, through cloud-native mechanisms.
• Continuous compliance. Compliance with the baseline should be monitored continuously — drift should be detected and remediated.
• Change management. Changes to database configuration should follow change control processes — evaluated for impact, tested, approved, and documented.
• Exception management. Some databases require deviations from baseline — for application compatibility, for specific business requirements. Exceptions should be documented, time-bounded, and reviewed.

09 Backup, recovery, and integrity

Database security is not only about protecting data from unauthorised access. It is also about ensuring that data remains available, that it can be recovered if lost or corrupted, and that its integrity can be verified.

Database backup

Database backup is the practice of creating copies of the database — protecting against data loss from various causes:

• Ransomware. Ransomware frequently targets databases and their backups (Lesson 3.4). Backups isolated from production — offline, immutable — are essential.
• Accidental deletion. Users or administrators may accidentally delete data — backups provide recovery.
• Corruption. Data may become corrupted — through storage failure, through software bugs, through malicious modification — backups provide recovery.
• Disaster. Natural disasters, facility failures, and other events may destroy databases — backups provide recovery.
• Compliance. Many regulations require database backups — both for availability and for retention.

Database backup security

Backups are frequently less well-protected than the primary databases — producing a recurring source of exposure. Securing database backups requires:

• Encryption. Backups should be encrypted — protecting the data if the backup media or storage is compromised.
• Access control. Access to backups should be restricted — limited to the systems and administrators that require it.
• Isolation. Backups should be isolated from production — offline, immutable, or in a separate security domain — reducing the risk of ransomware or other attacks affecting them.
• Integrity verification. Backups should be verified — confirming that they are complete, uncorrupted, and restorable.
• Retention. Backups should be retained according to policy — meeting regulatory requirements while minimising exposure.
• Key management. Encryption keys for backups should be managed securely — separate from the backup itself.

Database recovery

Recovery is the process of restoring the database from backup — and it is only as effective as the backup and the recovery process:

• Documented recovery procedures. Recovery procedures should be documented — with clear steps, defined responsibilities, and realistic timeframes.
• Tested recovery. Recovery should be tested regularly — backups that have never been restored may not be restorable.
• Recovery objectives. Recovery objectives — RTO and RPO (Recovery Time Objective and Recovery Point Objective) — should be defined based on the database's criticality.
• Recovery capability. The ability to recover within the stated objectives should be verified — including through exercises and through actual recovery operations.
• Recovery security. Recovery operations should be secure — through controlled access, through verification, through auditing.

Database integrity

Database integrity ensures that the data in the database is accurate and that it has not been modified without authorisation:

• Database integrity mechanisms. Constraints, referential integrity, and other database-level mechanisms that ensure data consistency.
• Transaction integrity. ACID (Atomicity, Consistency, Isolation, Durability) properties that ensure transactions are processed reliably.
• Integrity monitoring. Detection of unauthorised modification — through audit logs, through comparison against known state, through cryptographic verification.
• Integrity verification. Periodic verification that the database's data is accurate — through reconciliation, through comparison with source data.
• Integrity in recovery. Recovery procedures should preserve integrity — recovering to a consistent state, not to a corrupt or partially-restored state.

10 Cloud databases and data services

Cloud databases and data services introduce specific security considerations. The principles — access control, encryption, auditing, hardening, backup — remain the same, but the implementation adapts to the cloud environment and the shared responsibility model.

Cloud database models

Cloud database security considerations

Cloud database security in practice

Effective cloud database security involves:

• Understand the shared responsibility model for each cloud database service — what the provider manages and what the enterprise must manage.
• Configure cloud identity carefully. Use least privilege for cloud identity — IAM roles, service accounts, and federation — with the minimum permissions required.
• Prevent public exposure. Ensure cloud databases are not publicly accessible unless specifically required — and even then, only through controlled interfaces.
• Enable encryption. Enable encryption at rest and in transit for all cloud databases — with key management appropriate to the enterprise's requirements.
• Configure auditing. Enable cloud-native auditing — capturing the events that matter and integrating with the enterprise's SIEM.
• Implement CSPM. Use cloud security posture management to detect misconfiguration continuously.
• Protect backups. Cloud database backups should be encrypted, isolated, and access-restricted — as with on-premises backups.
• Monitor activity. Monitor cloud database activity — detecting anomalies that may indicate compromise or misuse.

11 Common pitfalls

Enterprise database security programmes fail in predictable ways. Recognising the pitfalls accelerates improvement.

Pitfall 1 — Over-privileged application accounts

Application accounts with administrative privileges or with access to tables the application does not use — turning a compromise of the application into a compromise of the database.

Mitigation: Apply least privilege to application accounts. Grant only the privileges the application requires.

Pitfall 2 — Unencrypted databases

Databases and backups without encryption — permitting data exposure if storage, backups, or snapshots are compromised.

Mitigation: Enable encryption at rest — through TDE, through storage encryption, through column-level encryption for the most sensitive data.

Pitfall 3 — Weak key management

Encryption keys stored in files, in configuration, or in application code — permitting data exposure if keys are compromised.

Mitigation: Store encryption keys in HSMs, in key management services, or in database-native secure key management. Rotate keys periodically.

Pitfall 4 — Insufficient auditing

Databases without auditing — producing no record of database activity and limiting detection, investigation, and compliance.

Mitigation: Enable database auditing. Configure it to capture the events that matter. Integrate logs with SIEM.

Pitfall 5 — Audit logs not monitored

Auditing enabled but logs not monitored — producing records that are examined only after an incident, if at all.

Mitigation: Integrate database logs with SIEM. Monitor for anomalies. Investigate alerts.

Pitfall 6 — Backup exposure

Backups that are less well-protected than primary databases — unencrypted, accessible, or connected to production.

Mitigation: Protect backups as rigorously as primary databases — encrypted, isolated, access-restricted.

Pitfall 7 — Cloud database misconfiguration

Cloud databases deployed with insecure defaults — public access, missing encryption, permissive IAM policies.

Mitigation: Configure cloud databases securely. Implement CSPM. Monitor for misconfiguration.

Pitfall 8 — Unmanaged database accounts

Database accounts accumulated over time — service accounts, application accounts, user accounts — without inventory or review.

Mitigation: Inventory database accounts. Review accounts and privileges periodically. Remove accounts that are no longer needed.

Pitfall 9 — Default accounts and credentials

Default database accounts with well-known credentials — providing well-known entry points for adversaries.

Mitigation: Disable or remove default accounts. Enforce strong credentials on all remaining accounts.

Pitfall 10 — No integration with application security

Database security treated as separate from application security — missing the interaction between the two.

Mitigation: Integrate database security with application security. Consider how application compromise affects database security and vice versa.

12 Key concepts

The terms below are used throughout Unit 5. Capture them in your own words as you work through the lesson.

Database security

The discipline of protecting databases and the data they hold — through access control, encryption, auditing, masking, hardening, and backup and recovery.

Database attack surface

The interfaces, components, and data through which databases can be attacked — network interface, accounts, privileges, stored procedures, integrations, data, backups, software, management interfaces, and logs.

Database access control

The discipline of determining which accounts can access which data — through database roles, privileges, and account management.

Database account

An account through which users, applications, services, or administrators access the database. Categories include administrative, application, user, service, and default accounts.

Application account

A database account used by an application to access the database. Frequently over-privileged and frequently the source of database compromise.

Database privilege

The permissions granted to a database account — system privileges, object privileges, administrative privileges.

Row-level security (RLS)

Access control at the row level — permitting users to access only specific rows based on policy. Supported by many modern database platforms.

Transparent Data Encryption (TDE)

Encryption of the database files at the database level — transparent to applications. Supported by most enterprise database platforms.

Column-level encryption

Encryption of specific columns within the database — providing more granular protection for the most sensitive data.

Key management

The set of practices for generating, distributing, storing, using, rotating, and destroying cryptographic keys. Examined in Lesson 2.1.

Hardware Security Module (HSM)

A dedicated hardware device for generating, storing, and using cryptographic keys — with strong protection against extraction or misuse.

BYOK (Bring Your Own Key)

The practice of bringing the enterprise's own keys to a cloud provider's key management service — providing control over key lifecycle.

HYOK (Hold Your Own Key)

The practice of holding the enterprise's own keys outside the cloud provider — providing the strongest control but the most operational complexity.

Database auditing

The recording of database activity — authentication, privilege changes, administrative operations, data access, and other events.

Database Activity Monitoring (DAM)

Specialised tools that monitor database activity — providing detection of suspicious activity, frequently with real-time blocking capabilities.

Data masking

The practice of replacing sensitive data with substitutes that preserve the data's usefulness for specific purposes while protecting its confidentiality. Includes static and dynamic masking.

Static data masking

Sensitive data replaced with substitutes in a copy of the database — for development, testing, or analytics.

Dynamic data masking

Sensitive data masked at query time — based on the requesting user's privileges.

Tokenisation

Sensitive data replaced with a token — a non-sensitive substitute that references the original data held in a separate, protected system.

Pseudonymisation

Sensitive identifiers replaced with pseudonyms — consistent substitutes that permit linking without identifying the subject.

Anonymisation

Sensitive data modified so that individuals cannot be identified — through suppression, generalisation, or perturbation.

Data minimisation

The principle of reducing the volume of sensitive data the enterprise holds — collecting only what is needed, retaining only as long as needed, disposing securely.

Database hardening

Reducing the attack surface of the database platform to the minimum required — network hardening, account hardening, configuration hardening, and data hardening.

Recovery Time Objective (RTO)

The maximum acceptable time to restore a system or data after disruption. A business decision, not a technical one.

Recovery Point Objective (RPO)

The maximum acceptable data loss measured in time. A business decision, not a technical one.

Cryptographic erasure

The destruction of data by destroying the encryption keys that protected it — making the data unrecoverable without the keys.

13 Activities

The activities below help you test your understanding and prepare for the unit discussion and Assignment 2. They are not graded, but completing them will substantially improve your preparation.

14 Self-check

Answer the questions below before moving to Lesson 5.5. If you cannot answer a question confidently, revisit the corresponding section.

15 Summary

This lesson has examined database security — the discipline of protecting the data stores on which applications depend and which hold the enterprise's most sensitive information. The essential points are:

• Database security matters because databases hold the enterprise's most valuable data. They are targeted directly, subject to regulation, and central to enterprise operations.
• The database attack surface is broad. Network interface, accounts, privileges, stored procedures, integrations, data, backups, software, management interfaces, and logs.
• Database access control governs who can access what. Accounts, privileges, roles, and row-level and column-level security — with least privilege for application accounts.
• Database encryption protects data at rest, in transit, and in use. TDE, column-level encryption, TLS, and emerging confidential computing — with key management as the foundation.
• Database auditing records activity. Authentication, privilege changes, administrative operations, data access, and other events — with protection of logs and integration into SIEM.
• Data masking and privacy controls reduce the exposure of sensitive data. Static masking, dynamic masking, tokenisation, pseudonymisation, anonymisation — with data minimisation as the first principle.
• Database hardening reduces the attack surface. Network hardening, account hardening, configuration hardening, and data hardening — informed by benchmarks.
• Backup, recovery, and integrity ensure availability. Protecting backups, testing recovery, and verifying data integrity — with backups protected as rigorously as primary databases.
• Cloud databases introduce specific considerations. Shared responsibility, cloud identity, network exposure, encryption, monitoring, data residency — with misconfiguration as the most consequential risk.
• Common pitfalls recur. Over-privileged application accounts; unencrypted databases; weak key management; insufficient auditing; audit logs not monitored; backup exposure; cloud database misconfiguration; unmanaged accounts; default accounts; no integration with application security.

These ideas prepare for Lesson 5.5, which examines cloud security — the discipline of protecting workloads, data, and identities in cloud environments, and which integrates the material from Lessons 5.1–5.4 within the shared responsibility model.