Data Security, Privacy and Cryptography

Introduction

Cloud computing changes where data is stored, processed and transmitted. Information may move among user devices, cloud regions, backup systems, analytics platforms, software services and subprocessors. This flexibility creates significant benefits, but it also complicates confidentiality, integrity, availability, privacy, legal control and accountability.

Data security is the protection of information against unauthorized access, alteration, disclosure, loss and destruction. Privacy concerns the lawful and ethical collection, use, sharing and retention of information about identifiable people. Cryptography provides technical mechanisms—such as encryption, hashing, digital signatures and key management—that support both security and privacy, but cryptography alone cannot solve poor identity management, excessive data collection or inappropriate retention.

A sound cloud data-protection programme therefore follows the complete data lifecycle: identify and classify data, collect it lawfully, protect it in use and transit, monitor its handling, retain it only as necessary, and securely delete it when its purpose ends.

Learning Objectives

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

1. Explain data classification and the cloud data lifecycle.
2. Distinguish encryption, hashing, tokenization, masking and anonymization.
3. Select suitable controls for data at rest, in transit and in use.
4. Explain key-management principles and common cryptographic algorithms.
5. Design practical data-loss prevention and secure-deletion controls.
6. Analyse privacy, data-sovereignty and data-residency requirements.
7. Evaluate a cloud data-security architecture and its governance implications.

1. Data as a Security and Governance Asset

Data has different value, sensitivity and regulatory significance. A public product brochure does not require the same controls as payment-card data, health information or cryptographic keys. Classification makes protection proportional to risk.

A typical classification scheme is:

Classification should consider confidentiality, integrity, availability, privacy, legal obligations, business value and the consequences of unauthorized disclosure. A record may have multiple attributes: for example, a customer identifier can be confidential, personal data and subject to cross-border-transfer restrictions.

The Data Lifecycle

The lifecycle normally includes:

1. Create or collect — establish purpose, lawful basis, data quality and consent where required.
2. Store — select locations, services, backup policies and access controls.
3. Use and process — restrict access, record activity and prevent inappropriate secondary use.
4. Share or transmit — authenticate endpoints and protect communications.
5. Archive — preserve information only when there is a documented business or legal reason.
6. Delete or destroy — remove data and accessible copies, including temporary files and backups where feasible.

Cloud contracts must identify who controls the data, who processes it, where it may be located, which subprocessors are involved and how evidence of deletion will be supplied.

2. Cryptographic Foundations

Cryptography transforms information so that only an authorized party, or a party able to verify authenticity, can use it correctly.

Encryption

Encryption converts plaintext into ciphertext using an algorithm and a key. Decryption reverses the process. Modern encryption should use established, publicly analysed algorithms rather than proprietary secrecy.

Symmetric encryption uses the same secret key for encryption and decryption. It is efficient for databases, files, disks and high-volume network traffic. Examples include AES and ChaCha20. The main challenge is distributing and protecting the key.

Asymmetric cryptography uses a public-key and a private-key pair. Data encrypted with one key is processed using the corresponding key according to the algorithm’s design. It supports key exchange, digital signatures and identity verification, but is generally slower than symmetric encryption. Examples include RSA and elliptic-curve cryptography.

In practice, cloud systems use hybrid cryptography: asymmetric methods establish or protect a session key, and symmetric encryption protects the actual data.

Integrity and Authentication

A cryptographic hash function maps input of arbitrary length to a fixed-length digest. A secure hash is designed so that finding an input that produces a chosen digest is computationally impractical. Hashes support integrity checking, indexing and password-verifier designs, but a hash is not encryption because it is not intended to be reversed.

A message authentication code (MAC) combines a secret key with a message to provide integrity and origin authentication. A digital signature uses a private key to sign data and a public key to verify the signature. Signatures support non-repudiation-related evidence, although legal non-repudiation also depends on process, identity proof and evidential controls.

Passwords should not be stored as ordinary hashes. They should be processed using a password-specific, salted and deliberately expensive function such as Argon2id, scrypt or an appropriately configured PBKDF2 implementation. The salt prevents identical passwords from producing identical stored values and reduces the usefulness of precomputed tables.

Randomness and Nonces

Cryptographic keys, initialization vectors, salts and nonces require appropriate random generation. A nonce is generally intended to be used once within a defined cryptographic context. Reusing a nonce in modes such as AES-GCM can seriously compromise confidentiality and authentication. Random values must come from a cryptographically secure random-number generator, not an ordinary predictable programming-language random function.

3. Protecting Data in Different States

Data at Rest

Data at rest includes databases, object stores, disks, snapshots, logs, queues, backups and removable media. Controls include:

• storage-level or volume encryption;
• database or column-level encryption for especially sensitive fields;
• separate protection of encryption keys and data;
• access policies based on identity, role, workload and context;
• backup encryption and restoration testing; and
• logging of administrative and data-access events.

Storage encryption reduces exposure if media or snapshots are obtained. It does not prevent an authorized but malicious application, administrator or compromised identity from reading data through a legitimate interface. Application-level encryption, tokenization and strict authorization may therefore be required.

Data in Transit

Transport Layer Security (TLS) protects application communications when correctly configured and authenticated. Administrators should disable obsolete protocol versions and weak cipher suites, validate certificates, protect private keys and monitor certificate expiry. Mutual TLS can authenticate both communicating services and is useful for service-to-service communication.

Encryption must cover internal traffic as well as internet traffic where the threat model includes compromised networks, shared infrastructure or lateral movement. Network segmentation complements, but does not replace, cryptographic protection.

Data in Use

Data in use is exposed while being processed in memory or presented to an authorized user. Controls include minimizing fields returned to applications, using short-lived credentials, applying role- and attribute-based access control, isolating workloads and preventing sensitive data from appearing in logs. Confidential-computing technologies, including trusted execution environments, can reduce exposure in selected workloads, but their security depends on hardware, configuration, attestation and operational governance.

4. Key Management

Cryptographic security is limited by the protection of keys. Key management includes generation, registration, storage, distribution, use, rotation, backup, recovery, revocation, archival and destruction.

A professional design separates duties and avoids placing keys beside the data they protect without additional controls. Cloud key-management services and hardware security modules (HSMs) can generate and protect keys, enforce access policies and provide audit records. However, using a managed service does not transfer all responsibility: the customer still must configure permissions, select regions, manage administrators and test recovery.

Important practices include:

• maintain an inventory of keys, owners, purposes and associated data;
• use the minimum permission necessary for each key operation;
• separate key administrators from data administrators;
• define rotation based on risk, algorithm policy and exposure—not merely calendar habit;
• plan for key compromise, revocation and emergency replacement;
• protect backup copies and recovery material;
• record key-use events and investigate anomalies; and
• destroy retired keys only after confirming legal, operational and recovery requirements.

Key rotation does not automatically re-encrypt all historical data. Systems may use envelope encryption, in which a data-encryption key protects the data and a key-encryption key protects the data-encryption key. Rotating the key-encryption key can be efficient, but the design must document which versions decrypt existing objects.

5. Tokenization, Masking and Anonymization

Tokenization replaces a sensitive value with a non-sensitive token. A token vault or cryptographic mapping allows authorized systems to recover the original value. Tokenization is useful for payment identifiers and testing environments, but the vault becomes highly sensitive and must be strongly protected.

Masking hides part of a value, such as displaying only the last four digits of an account number. Static masking creates a transformed copy; dynamic masking changes what a user sees according to authorization. Masking is helpful for support and development, but it is not necessarily irreversible and should not be treated as encryption or anonymization.

Anonymization aims to make re-identification impossible or sufficiently impractical in the relevant context. Removing names is not enough if combinations of dates, locations and rare characteristics identify individuals. Pseudonymization replaces identifiers while retaining a separately protected means of linkage; it reduces exposure but remains personal-data processing in many legal frameworks.

Data minimization should precede transformation: the safest sensitive field is one that is never collected or retained.

6. Data Loss Prevention and Monitoring

Data loss prevention (DLP) identifies and controls unauthorized movement or use of sensitive information. DLP may inspect content, metadata, context and user behaviour across endpoints, email, collaboration platforms, cloud storage and network channels.

A DLP programme should:

1. define sensitive-data patterns and classification labels;
2. establish approved destinations and business purposes;
3. distinguish detection, warning, quarantine and blocking actions;
4. reduce false positives through testing and exception governance;
5. integrate alerts with incident response; and
6. protect DLP logs because they may contain sensitive content.

DLP is not a substitute for access control. It may fail when data is encrypted before inspection, hidden in images, fragmented across records or transferred through an unmonitored channel. Behavioural analytics and machine-learning classifiers can assist discovery, but their decisions require testing for accuracy, bias, explainability and privacy impact.

7. Retention and Secure Deletion

Retention must balance legal preservation, business usefulness, privacy and cost. A retention schedule should state the data category, responsible owner, minimum and maximum period, legal hold process, archive location and disposal method.

Over-retention increases breach impact, discovery cost and privacy risk. Under-retention can violate legal duties, undermine audits or destroy evidence. Legal holds must suspend ordinary deletion for relevant information, while avoiding indefinite retention of unrelated data.

Secure deletion is more complex in cloud environments because data may exist in replicas, snapshots, caches, indexes, logs and backups. Appropriate techniques depend on the medium and service architecture. Logical deletion may make data inaccessible through normal interfaces; cryptographic erasure destroys or revokes the keys required to decrypt it; physical destruction may be performed by a provider for retired media. Organizations should obtain contractual commitments and deletion evidence, while recognizing that backup expiration may occur later than primary deletion.

8. Privacy, Sovereignty and Residency

Privacy governance begins with purpose limitation, data minimization, accuracy, transparency, access rights and accountability. A privacy impact assessment should be considered for large-scale monitoring, sensitive information, automated decision-making, new data uses and international transfers.

The following concepts must be distinguished:

• Data residency: the geographic location where data is stored or processed.
• Data sovereignty: the legal authority and jurisdiction that may apply to data because of its location, provider, owner or processing activity.
• Data localization: a legal or policy requirement that data remain within a specified jurisdiction or that certain processing occur locally.

Selecting a cloud region does not by itself guarantee sovereignty. Support personnel, subprocessors, telemetry, backups and remote administration may create additional transfer paths. A due-diligence review should examine provider terms, government-access processes, subprocessor lists, encryption control, contractual transfer mechanisms and the customer’s ability to audit.

Privacy-enhancing technologies include encryption with customer-controlled keys, tokenization, pseudonymization, aggregation, differential privacy and secure multiparty computation. Each has trade-offs. For example, stronger anonymization may reduce analytical usefulness, while differential privacy introduces carefully controlled statistical noise. Privacy is therefore an architectural property, not merely a compliance document.

9. Applied Case: Health-Services Analytics Platform

The following is an illustrative case.

Background

A regional health provider wants to move appointment, billing and clinical data to a cloud analytics platform. Analysts need population-level trends, while clinicians need identifiable records. The provider operates in several jurisdictions with different transfer and retention requirements.

Problem

The initial design stores identifiable records in a shared object store, grants analysts broad read access and copies production data into development accounts. Backups are not consistently classified, and the provider cannot demonstrate where support-generated logs are processed.

Analysis

The data has high confidentiality and privacy impact. A single encryption layer at the storage service would not address excessive analyst privileges, development copies, log leakage or uncertain residency. The provider also needs separate controls for clinical use, billing, research and operational support.

Approach and Solution

The redesigned architecture:

• classifies clinical and identity fields as restricted;
• stores direct identifiers in a segregated, tightly controlled service;
• tokenizes patient references before analytics processing;
• encrypts databases, objects, backups and service connections;
• uses a customer-controlled key hierarchy with separate production and development administration;
• applies attribute-based access policies for role, purpose and jurisdiction;
• provides masked datasets for development and synthetic data where feasible;
• blocks exports containing restricted fields through DLP policies;
• records access, key use, administrative actions and data exports;
• applies documented retention schedules and tested deletion workflows; and
• contracts for approved regions, subprocessor transparency and deletion evidence.

Outcome

Analysts can answer population-level questions without routinely viewing names or clinical narratives. Clinicians retain controlled access to identifiable records. The provider can demonstrate data flows, investigate unusual access and respond more reliably to data-subject requests and regulatory inquiries.

Learning Points

The case illustrates that security is layered. Encryption, tokenization, identity governance, DLP, contractual controls and retention management solve different problems. It also shows why privacy requirements must be included during architecture design rather than added after migration.

10. Governance, Ethics and Contemporary Practice

Data protection requires clear accountability among the cloud provider, customer, application owner, security team, privacy officer and data subjects. Policies should define acceptable use, privileged access, incident notification, evidence preservation and third-party risk management.

Ethically, organizations should avoid collecting data merely because storage is inexpensive. Automated classification and anomaly detection can expose sensitive information or unfairly scrutinize users. Human review, proportionality, transparency and appeal mechanisms are important when security tools affect individuals.

Contemporary practice increasingly combines confidential computing, customer-managed keys, zero-trust access, privacy-enhancing analytics and automated discovery. Artificial intelligence can classify documents and detect unusual data movement, but training data, model prompts, retained logs and generated outputs can themselves contain sensitive information. AI services therefore require explicit data-use terms, retention controls, access restrictions and validation against leakage.

Best-Practice Design Checklist

• Catalogue data stores, flows, owners and subprocessors.
• Classify information before selecting controls.
• Minimize collection and restrict secondary use.
• Encrypt data at rest and in transit using approved algorithms and configurations.
• Protect keys independently, monitor their use and rehearse compromise recovery.
• Use tokenization or pseudonymization where full identity is unnecessary.
• Apply least privilege, purpose limitation and strong authentication.
• Extend controls to logs, snapshots, backups, caches and development environments.
• Implement DLP with tested policies and an incident-response path.
• Document residency, sovereignty and transfer requirements.
• Maintain retention schedules, legal holds and deletion evidence.
• Test restoration, access revocation, key rotation and secure deletion.

Chapter Summary

Data security and privacy depend on controlling information throughout its lifecycle. Classification makes protection proportional to sensitivity and consequence. Encryption protects confidentiality, while hashes, MACs and digital signatures support integrity and authentication. Symmetric cryptography is efficient for bulk data; asymmetric cryptography supports identity and key exchange. Secure key management is as important as algorithm selection.

Tokenization, masking, pseudonymization and anonymization have different purposes and residual risks. DLP, least privilege, monitoring and data minimization reduce unauthorized disclosure. Retention and secure deletion must include cloud replicas, backups and logs. Privacy, residency and sovereignty require analysis of jurisdictions, subprocessors, support operations and transfer mechanisms. Effective cloud protection is therefore a combined technical, organizational, legal and ethical discipline.

Key Terms

Data classification: Categorizing information according to sensitivity, value and required protection.

Data lifecycle: The stages through which data passes from collection to deletion.

Encryption: Transformation of plaintext into ciphertext using a cryptographic key.

Symmetric cryptography: Cryptography using a shared secret key for related encryption and decryption operations.

Asymmetric cryptography: Cryptography using a mathematically related public-key and private-key pair.

Hash function: A one-way function that produces a fixed-length digest from input data.

MAC: A keyed mechanism providing message integrity and authentication.

Digital signature: A private-key-generated value verifiable with a public key.

Nonce: A value intended for one-time use in a defined cryptographic context.

Key management: Generation, protection, distribution, rotation, recovery and destruction of cryptographic keys.

HSM: Hardware security module that protects cryptographic operations and keys.

Envelope encryption: Protecting a data-encryption key with a separate key-encryption key.

Tokenization: Replacing sensitive data with a controlled substitute token.

Masking: Concealing all or part of a value from a viewer.

Pseudonymization: Replacing identifiers while retaining a separately protected linkage capability.

Anonymization: Transforming data so individuals cannot reasonably be re-identified in context.

DLP: Controls that detect and restrict unauthorized movement or use of sensitive data.

Data residency: The geographic location in which data is stored or processed.

Data sovereignty: The jurisdictional authority applicable to data and its processing.

Cryptographic erasure: Making data inaccessible by securely destroying or revoking its decryption keys.

Review Questions

Short Answer Questions

1. Why is data classification necessary in a cloud environment?
2. Distinguish encryption from hashing.
3. What is the purpose of a key-encryption key in envelope encryption?
4. Why is masking not equivalent to anonymization?
5. Define data residency and data sovereignty.

Long Answer Questions

1. Explain how an organization should protect data at rest, in transit and in use.
2. Discuss the complete lifecycle of cryptographic keys and the consequences of poor key management.
3. Compare tokenization, masking, pseudonymization and anonymization, including suitable use cases.
4. Explain how retention, legal holds and secure deletion should be managed in cloud platforms.
5. Evaluate the relationship between privacy governance, data minimization and cloud architecture.

Analytical / Application Questions

1. A company encrypts its database but gives all analysts unrestricted read access. Analyse the remaining risks and propose layered controls.
2. A multinational organization wants one global data lake containing customer records, logs and backups. Design a decision process addressing classification, residency, sovereignty, subprocessors and retention.
3. During an incident, an attacker obtains an application identity that can decrypt production data. Analyse how key separation, tokenization, DLP and monitoring could limit the impact and support recovery.

Multiple Choice Questions with Answers

Question 1

Which control primarily protects the confidentiality of data stored in a cloud object store?

A. Encryption at rest

B. A data-retention schedule

C. A checksum displayed to users

D. A public access URL

Correct Answer: A. Encryption at rest

Question 2

What is the main purpose of a cryptographic hash function?

A. To provide reversible encryption

B. To support integrity checking

C. To distribute private keys

D. To remove all personal data

Correct Answer: B. To support integrity checking

Question 3

Which statement best describes tokenization?

A. It replaces a sensitive value with a controlled substitute

B. It permanently deletes the original value

C. It hides only the last four characters

D. It guarantees that re-identification is impossible

Correct Answer: A. It replaces a sensitive value with a controlled substitute

Question 4

Why should encryption keys be protected separately from the data they encrypt?

A. To make data classification unnecessary

B. To ensure storage encryption is always reversible

C. To reduce the impact of compromise of the data store

D. To eliminate the need for authentication

Correct Answer: C. To reduce the impact of compromise of the data store

Question 5

Which technology is most directly associated with authenticating both ends of a service-to-service connection?

A. Static masking

B. Mutual TLS

C. Data archiving

D. Database indexing

Correct Answer: B. Mutual TLS

Question 6

A pseudonymized dataset is generally still considered sensitive because:

A. It cannot be stored in a cloud

B. The linkage to the individual may still exist

C. It is always publicly available

D. It contains no transformed values

Correct Answer: B. The linkage to the individual may still exist

Question 7

Which action is an example of data minimization?

A. Keeping every historical log indefinitely

B. Collecting only the fields needed for the stated purpose

C. Copying production data into every development account

D. Granting all analysts unrestricted access

Correct Answer: B. Collecting only the fields needed for the stated purpose

Question 8

What is cryptographic erasure?

A. Deleting a user interface shortcut

B. Destroying or revoking keys needed to decrypt data

C. Compressing encrypted backups

D. Changing a password without changing its permissions

Correct Answer: B. Destroying or revoking keys needed to decrypt data

Question 9

Why does selecting a cloud region not necessarily guarantee data sovereignty?

A. Cloud regions cannot store encrypted data

B. Support staff, subprocessors or backups may involve other jurisdictions

C. Encryption always moves data to a public region

D. Residency and sovereignty are identical concepts

Correct Answer: B. Support staff, subprocessors or backups may involve other jurisdictions

Question 10

Which practice is most appropriate for passwords?

A. Store them in plaintext for recovery

B. Encrypt them with a shared database key

C. Use a salted, deliberately expensive password-specific function

D. Use a short unsalted hash

Correct Answer: C. Use a salted, deliberately expensive password-specific function