Protecting Data at Rest and in Use

Introduction

Data protection does not end when information has been encrypted during transmission. Information is also exposed when it is stored on a laptop, database, backup system, cloud platform, removable drive, or endpoint. It may be exposed while an authorised application, administrator, analyst, or cloud service is actively processing it. These conditions are commonly described as data at rest and data in use.

Data at rest includes persistent information stored in files, databases, virtual machines, object storage, archives, backups, and devices. Data in use includes information held in memory, loaded into application processes, displayed on screens, copied into temporary files, or processed by analytics and artificial-intelligence systems. The controls selected must reflect the threat, the sensitivity of the data, operational requirements, and the consequences of compromise.

Encryption is important, but it is not a complete data-protection strategy. Access control, key management, secure configuration, monitoring, retention management, deletion, masking, tokenization, and sound governance are equally significant. A disk encrypted with a key stored carelessly may provide little protection. Similarly, a database protected by encryption may still disclose sensitive information to an authorised but misused account.

Learning Objectives

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

• distinguish data at rest, data in transit, and data in use;
• select suitable controls for files, disks, databases, backups, endpoints, and cloud storage;
• explain full-disk, volume, file, field-level, and application-level encryption;
• compare encryption, tokenization, masking, and redaction;
• describe key-management and secure-deletion requirements;
• explain the fundamentals and limitations of confidential computing;
• apply these controls to a realistic organisational scenario;
• recognise governance, privacy, operational, and ethical implications.

1. Data States and Protection Objectives

The traditional three-state model identifies:

This chapter concentrates on data at rest and in use, although controls must operate as a coordinated system. The principal security objectives are:

• Confidentiality: preventing unauthorised disclosure;
• Integrity: preventing unauthorised alteration;
• Availability: ensuring data remains usable when required;
• Accountability: recording who accessed or changed information;
• Privacy: limiting collection, use, retention, and disclosure of personal data.

A useful design principle is defence in depth. For example, a sensitive customer database may use host hardening, encrypted storage, field-level encryption, role-based access, database auditing, backup encryption, network segmentation, and retention controls. No individual control should be treated as a substitute for the others.

2. Encryption at Rest

Encryption transforms plaintext into ciphertext using a cryptographic algorithm and a key. Modern systems generally use authenticated encryption, which provides confidentiality and detects unauthorised modification. The security of encryption depends not only on the algorithm but also on key secrecy, key generation, access control, implementation quality, and recovery procedures.

Full-Disk and Volume Encryption

Full-disk encryption (FDE) encrypts most or all sectors of a storage device. Volume or partition encryption applies similar protection to a logical volume. These controls are particularly valuable when a laptop, removable drive, or server disk is lost or stolen.

FDE normally protects data when the device is powered off. After a legitimate user unlocks the device, the operating system and applications can read plaintext. Consequently, FDE does not by itself prevent malware, an unauthorised logged-in user, or an administrator with excessive privileges from accessing data.

FDE should be combined with:

• strong authentication and, where practical, multifactor authentication;
• secure boot and trusted-platform features;
• centrally managed recovery keys;
• endpoint detection and response;
• patching and least privilege;
• documented recovery testing.

A recovery key stored only on the device is not a reliable recovery design. Conversely, unrestricted access to a central recovery-key repository creates a high-impact target.

File and Folder Encryption

File-level encryption protects selected files or directories rather than an entire device. It can reduce exposure when only a subset of information is sensitive and may support different keys for different users or applications. It is useful for portable files, exports, and document repositories.

However, file-level encryption can leave metadata, filenames, temporary copies, indexes, cached previews, and deleted remnants exposed. Applications may also create unencrypted working copies. The design must therefore include temporary storage, logs, backups, and collaboration tools.

Database and Field-Level Encryption

Database encryption may operate at several layers:

1. Storage or tablespace encryption protects database files and disks.
2. Transparent database encryption encrypts data files and often logs while allowing the database engine to operate normally.
3. Column or field-level encryption protects selected attributes, such as national identification numbers or payment details.
4. Application-level encryption encrypts data before it reaches the database.

Field-level encryption limits exposure more effectively than storage encryption when database administrators, stolen backups, or SQL exports are within the threat model. It also introduces complexity: searching, sorting, indexing, joins, reporting, and key rotation may become more difficult.

Deterministic encryption can permit equality searches because the same plaintext produces the same ciphertext, but repeated values become visible and frequency analysis may reveal patterns. Randomised encryption uses a fresh nonce or random value and normally provides stronger semantic confidentiality, but direct equality searches are not straightforward. The choice must be based on a documented requirement rather than convenience.

Key Management

A cryptographic key should be treated as a protected asset. Key management includes generation, distribution, storage, use, rotation, backup, recovery, revocation, destruction, and audit.

A common architecture uses a hierarchy:

• a hardware security module or cloud key-management service protects high-value key-encryption keys;
• data-encryption keys protect files, records, or volumes;
• key-encryption keys encrypt or wrap the data-encryption keys.

This arrangement supports rotation of higher-level keys without re-encrypting every data object, although exact behaviour depends on the implementation. Separation of duties is desirable: a person who administers storage should not automatically control all cryptographic keys.

Key-management questions include:

• Who can request decryption?
• Which service identity is authorised?
• How is access logged?
• What happens if a key is unavailable?
• How are keys recovered after disaster?
• How are retired keys preserved if old data must still be decrypted?
• How is destruction verified when legal retention ends?

Encryption can fail operationally if keys are lost, rotated without dependency analysis, or made accessible through source code, configuration files, or unprotected environment variables.

3. Backups, Archives, and Cloud Storage

Backups often contain more information than production systems because they preserve historical records. They may also be copied to another region, a supplier, or removable media. Backup protection should include encryption in transit and at rest, strong access control, immutable or offline copies where appropriate, and regular restoration testing.

A backup strategy should define:

• what is backed up and how often;
• retention periods and legal holds;
• who can restore data;
• whether backups are encrypted before leaving the organisation;
• where keys are held;
• how ransomware-resistant copies are created;
• how restored data is protected and deleted afterward.

Cloud object storage introduces a shared-responsibility model. The provider may secure physical facilities and platform infrastructure, while the customer remains responsible for identity permissions, bucket or container configuration, key choices, data classification, logging, and retention. Provider-managed encryption is useful but does not correct an overly permissive identity policy or a publicly exposed object.

Customer-managed keys can improve control and separation, but they increase operational responsibility. If the customer disables or destroys the key, encrypted objects may become inaccessible. Cross-region replication, outsourced processing, and provider support access should be included in the threat and compliance assessment.

4. Tokenization, Masking, and Redaction

Encryption is reversible using a key. Other techniques may reduce the exposure of sensitive values without retaining the original value in ordinary application workflows.

Tokenization

Tokenization replaces a sensitive value with a token. A token vault or cryptographic mechanism maintains the relationship between the token and the original value. For example, a payment number may be replaced with a token used by a merchant’s order system.

Tokenization can reduce the number of systems that handle original data, thereby reducing exposure and compliance scope. It does not eliminate the need to protect the token service, token vault, access controls, backups, and APIs. Tokens must not be assumed to be anonymous if they can be linked back to an individual.

Masking and Redaction

Masking shows only part of a value, such as the final four digits of an account number. Dynamic masking may display different representations according to the user’s role. Static masking creates a transformed copy, often for testing or analytics. Redaction removes or obscures information permanently in a document or output.

Masking is primarily a presentation or data-minimisation control. It does not necessarily protect the underlying database. A user who can query the raw column, inspect application responses, or access backups may still obtain the original value.

Hashing

A cryptographic hash creates a fixed-length digest. Hashing is appropriate for integrity checking and, with suitable password-specific techniques, password verification. It is not a general replacement for encryption because a hash is designed not to be reversed, while many low-entropy values can be guessed and compared.

For passwords, use a password-hashing function with a salt and an appropriate work factor, rather than a fast general-purpose hash. For searchable sensitive identifiers, hashing may still permit dictionary or frequency attacks and should be evaluated carefully.

5. Secure Deletion and Data Lifecycle Control

Deleting a filename does not necessarily erase its contents. Data may remain in free space, snapshots, replicas, caches, logs, backup sets, or hardware overprovisioning areas. Secure deletion therefore depends on the storage technology and the required assurance level.

Relevant techniques include:

• application deletion and removal of references;
• cryptographic erasure by destroying the key protecting data;
• sanitisation commands supported by storage devices;
• physical destruction when reuse is not appropriate;
• controlled disposal by an approved provider.

Overwriting may be effective for some magnetic media, but it is not a universal solution for modern solid-state devices, wear-levelled storage, snapshots, or replicated cloud platforms. Cryptographic erasure can be efficient when all copies are protected by independently managed keys, but it fails if plaintext copies or backup keys remain elsewhere.

A defensible deletion process identifies retention obligations, obtains approval, records the action, verifies scope, and preserves evidence. Legal holds and regulatory requirements may prohibit deletion even when an operational owner requests it.

6. Protecting Data in Use

Data in use is difficult to protect because legitimate computation normally requires access to plaintext. Controls therefore seek to reduce unnecessary exposure, isolate processing, restrict privileges, and detect misuse.

Important controls include:

• least-privilege service accounts;
• role-based and attribute-based access control;
• just-in-time administrative access;
• process isolation and sandboxing;
• endpoint hardening and application control;
• memory protection and secure coding;
• prevention of sensitive data in logs and error messages;
• screen-locking and privacy controls;
• database query monitoring and data-loss prevention;
• minimised datasets and short-lived credentials.

Applications should retrieve only the fields required for a task. A customer-support tool may need to confirm the last four digits of an account but not display the complete number. Analytics systems should use de-identified, aggregated, or synthetic data where feasible.

Confidential Computing Fundamentals

Confidential computing aims to protect data while it is being processed by placing computation inside a hardware-supported trusted execution environment (TEE). Memory is encrypted or isolated, and an attestation mechanism can allow a remote party to verify that an approved workload is running before releasing keys.

A simplified trust sequence is:

1. An application is packaged with an approved measurement or identity.
2. The TEE starts the workload and records its measurement.
3. A verifier checks an attestation statement from the platform.
4. If policy conditions are satisfied, a key-management service releases a data key.
5. The workload decrypts and processes data inside the protected environment.

Confidential computing can reduce exposure to a cloud operator, a compromised host operating system, or certain forms of infrastructure inspection. It does not automatically protect data from malicious code running inside the enclave, compromised application credentials, side-channel attacks, denial of service, bad inputs, or unauthorised output. Attestation policies, workload integrity, patching, logging, and output controls remain necessary.

TEE technologies differ in supported workloads, performance, memory limits, debugging methods, hardware assumptions, and resistance to side channels. Confidential computing should therefore be adopted for a defined threat model rather than as a universal security label.

7. Selecting Controls by Asset and Threat

Control selection should begin with classification and a threat assessment. The following guide is a starting point rather than a substitute for system-specific analysis.

A control is suitable only if it addresses a defined risk without creating unacceptable operational risk. For example, encrypting every database field may hinder essential searches and encourage insecure workarounds. A better design may encrypt especially sensitive fields, tokenize routine business references, and restrict the decryption service.

8. Applied Case: Regional Health-Services Provider

Background

This illustrative case concerns Northbridge Health, a regional provider operating clinics, a patient portal, mobile devices, analytics systems, and cloud backups. The organisation stores diagnoses, prescriptions, identity details, and payment information.

Problem

An unencrypted laptop containing a temporary export was stolen. Although the production database was encrypted at the storage layer, analysts used full patient records in a development environment. Backups were encrypted, but restoration keys were held by the same administrator who managed backup operations. Audit logs also recorded sensitive query parameters.

Analysis

The incident revealed several distinct weaknesses. FDE was absent from an endpoint, storage encryption did not protect against authorised database queries, development data exceeded business need, key duties were not separated, and logs created another disclosure path. The organisation had treated “encrypted” as a single control rather than a lifecycle architecture.

Approach and Solution

Northbridge introduced centrally managed FDE with tested recovery procedures. It applied field-level encryption or tokenization to highly sensitive identifiers and limited decryption to approved application services. Development datasets were replaced with masked and synthetic records. Backup keys were moved to a separately administered key-management service, and restoration required dual authorisation.

The organisation also removed sensitive query parameters from logs, implemented role-based access and periodic entitlement reviews, added cloud-storage policy checks, and defined retention and deletion schedules. A confidential-computing pilot was conducted for a multi-party research workload, with attestation required before release of research keys.

Outcome

The new controls reduced the impact of lost devices, narrowed the number of systems handling plaintext, improved separation of duties, and made access more auditable. They also introduced costs: application changes, key-recovery exercises, performance testing, and additional governance. The provider therefore documented exceptions and prioritised the highest-risk data rather than applying identical controls everywhere.

Learning Points

1. Storage encryption is not equivalent to application or field-level protection.
2. Development, logs, exports, and backups require the same lifecycle attention as production data.
3. Key management and recovery are central parts of encryption design.
4. Tokenization and masking reduce exposure but do not remove governance obligations.
5. Confidential computing supplements, rather than replaces, identity, application, and output controls.

9. Governance, Ethics, and Regulation

Data protection controls affect individuals and organisational accountability. Excessive collection and indefinite retention increase the consequences of compromise. Privacy principles commonly require purpose limitation, data minimisation, accuracy, security, retention control, and demonstrable accountability, although exact legal requirements vary by jurisdiction and sector.

Organisations should maintain data inventories, ownership assignments, classification rules, processing records, risk assessments, supplier requirements, incident procedures, and evidence of control testing. Contracts with cloud and processing providers should address access, breach notification, deletion, subcontracting, location, key control, and audit rights.

Encryption may reduce breach impact, but it does not automatically remove notification duties or prove that processing was lawful. Tokenized or pseudonymized data may remain personal data when re-identification is reasonably possible. Ethical practice also requires considering availability: poorly designed key controls can prevent patients, customers, or emergency personnel from accessing essential information.

10. Contemporary Developments and Best Practices

Current data-protection programmes increasingly combine zero-trust principles, cloud-native key management, confidential-computing services, automated discovery, and data-security posture management. Artificial-intelligence systems create additional concerns because prompts, training data, embeddings, intermediate results, and model logs may contain sensitive information. Organisations should establish rules for data submitted to AI services, use approved environments, minimise inputs, and prevent confidential outputs from entering uncontrolled systems.

Practical best practices include:

• classify information before choosing controls;
• encrypt devices, databases, backups, and cloud objects according to risk;
• protect high-risk fields at the application or tokenization layer;
• keep keys separate from the data they protect;
• use least privilege and strong service identities;
• test restoration, recovery, rotation, and deletion;
• mask or synthesise non-production data;
• exclude secrets and personal data from logs;
• monitor access and investigate unusual decryption or export activity;
• review supplier and cloud shared-responsibility boundaries;
• document exceptions, residual risks, and ownership.

Chapter Summary

Data at rest includes files, databases, backups, endpoints, and cloud objects, while data in use includes plaintext held in memory or processed by applications. Full-disk encryption is highly effective against lost or stolen devices but does not protect an unlocked system or authorised misuse. File, database, field-level, and application-level encryption provide progressively more targeted protection, with corresponding effects on searching, performance, and administration.

Encryption depends on disciplined key management, separation of duties, access control, recovery, and lifecycle governance. Tokenization, masking, redaction, and hashing serve different purposes and should not be treated as interchangeable. Secure deletion must account for replicas, snapshots, backups, and storage technology. Confidential computing uses hardware-supported trusted execution environments and attestation to reduce exposure during processing, but it does not eliminate application, identity, or output risks.

Effective protection is risk-based and layered. It includes minimisation, controlled access, monitoring, secure development, retention management, tested recovery, and responsible disposal. The central professional task is to select controls that protect confidentiality and privacy while preserving availability, usability, and accountability.

Key Terms

Data at rest: Information stored on persistent media or storage services.

Data in use: Information being processed, displayed, or held in active memory.

Full-disk encryption: Encryption covering most or all storage sectors on a device.

Volume encryption: Encryption applied to a logical storage volume or partition.

File-level encryption: Encryption applied to selected files or directories.

Field-level encryption: Encryption applied to selected database attributes or fields.

Application-level encryption: Encryption performed by an application before storage.

Authenticated encryption: Encryption that provides confidentiality and detects unauthorised modification.

Key management: Generation, storage, use, rotation, recovery, revocation, and destruction of cryptographic keys.

Tokenization: Replacement of sensitive values with controlled substitute tokens.

Masking: Hiding all or part of a value in a display or dataset.

Redaction: Permanent removal or obscuring of information from an output.

Hashing: Transformation of data into a fixed-length digest, normally designed to be one-way.

Secure deletion: A process intended to make stored information unrecoverable to the required assurance level.

Cryptographic erasure: Destruction of keys so that protected ciphertext can no longer be decrypted.

Trusted execution environment: Hardware-supported isolated environment for protected computation.

Attestation: Evidence used to verify the identity or state of a protected workload.

Data minimisation: Collecting, using, and exposing only the information necessary for a purpose.

Defence in depth: Use of multiple complementary controls so that one failure does not expose the entire system.

Shared responsibility: Division of security duties between a service provider and its customer.

Review Questions

Short Answer Questions

1. What is the principal protection provided by full-disk encryption, and what important risk remains after a device is unlocked?
2. How does field-level encryption differ from storage-layer database encryption?
3. Why should encryption keys be managed separately from the data they protect?
4. Distinguish tokenization from masking.
5. What is the purpose of attestation in confidential computing?

Long Answer Questions

1. Explain how an organisation should protect a sensitive database from storage compromise, excessive privileges, unauthorised exports, and backup exposure.
2. Compare full-disk, file-level, field-level, and application-level encryption, including their advantages and limitations.
3. Describe a complete lifecycle for cryptographic key management.
4. Explain why secure deletion is difficult in modern cloud and solid-state storage environments.
5. Discuss the governance and ethical issues involved in protecting personal data while maintaining availability.

Analytical / Application Questions

1. A company encrypts its production database and backups but sends complete customer records to an unprotected development environment. Identify the control failures and propose a revised design.
2. A cloud provider offers provider-managed encryption, while a customer requests customer-managed keys. Analyse the security, operational, recovery, and governance trade-offs.
3. A research consortium wants several organisations to analyse confidential datasets without exposing plaintext to the host cloud operator. Develop a control strategy using minimisation, access control, encryption, and confidential-computing principles.

Multiple Choice Questions with Answers

Question 1

Which control primarily protects a laptop when it is powered off and physically stolen?

A. Full-disk encryption

B. Database query logging

C. Dynamic data masking

D. Network segmentation

Correct Answer: A. Full-disk encryption

Question 2

What is a major limitation of storage-layer database encryption?

A. It prevents all authorised users from reading data

B. It may not protect plaintext returned through authorised queries

C. It cannot protect backup files

D. It always prevents indexing

Correct Answer: B. It may not protect plaintext returned through authorised queries

Question 3

What is the main purpose of tokenization?

A. To replace a sensitive value with a controlled substitute

B. To make a password easier to remember

C. To permanently delete all copies of a value

D. To compress a database column

Correct Answer: A. To replace a sensitive value with a controlled substitute

Question 4

Which statement about masking is correct?

A. It necessarily encrypts the underlying database

B. It displays or creates a limited representation of a value

C. It guarantees that re-identification is impossible

D. It replaces the need for access control

Correct Answer: B. It displays or creates a limited representation of a value

Question 5

Why is a cryptographic key-encryption key often used?

A. To replace authentication entirely

B. To protect data-encryption keys

C. To make plaintext publicly searchable

D. To remove the need for backups

Correct Answer: B. To protect data-encryption keys

Question 6

Which item is especially important when protecting backups?

A. Assuming backups have lower sensitivity than production data

B. Testing restoration and controlling recovery keys

C. Disabling all retention policies

D. Publishing backup locations

Correct Answer: B. Testing restoration and controlling recovery keys

Question 7

What does confidential computing primarily seek to protect?

A. Data while it is being processed in a protected execution environment

B. Only filenames in a file system

C. Only data transmitted between web browsers

D. Physical buildings without access controls

Correct Answer: A. Data while it is being processed in a protected execution environment

Question 8

Which technique is most appropriate for creating a non-production dataset when original personal values are unnecessary?

A. Using complete production records

B. Masking, tokenization, or synthetic data

C. Disabling database auditing

D. Storing exports in an unencrypted folder

Correct Answer: B. Masking, tokenization, or synthetic data

Question 9

Why is hashing generally not a replacement for encryption?

A. Hashing is intended to be one-way rather than decryptable

B. Hashing always produces variable-length plaintext

C. Hashing requires no computation

D. Hashing can only be used on images

Correct Answer: A. Hashing is intended to be one-way rather than decryptable

Question 10

Which statement best describes secure deletion?

A. Deleting a filename always destroys the underlying content

B. It must account for replicas, snapshots, backups, and storage technology

C. It is achieved only by changing a file extension

D. It requires publishing the deleted data

Correct Answer: B. It must account for replicas, snapshots, backups, and storage technology