Cloud Data Security · Topic 2 of 7
Encryption, Hashing and Key Management
CCSP data protection with encryption, envelope keys, hashing for integrity, digital signatures for non-repudiation, and keys, secrets and certificates.
- 5 min
- Encryption by the provider with its own keys does not protect against the provider.
- Envelope encryption: DEK encrypts data, KEK in a KMS or HSM encrypts the DEK.
- Hashing gives integrity; digital signatures add origin and non-repudiation.
What it is
Encryption keeps data confidential, hashing proves it has not changed, and digital signatures prove who sent it. All three depend on keys, secrets and certificates being managed well, which is where most cloud failures happen.
The CCSP view is design: where to encrypt, who holds the keys, and how secrets and certificates are issued, stored, rotated and revoked.
How it works
Where to encrypt
| Layer | Example | Protects against |
|---|---|---|
| Storage level | Provider encrypts disks or objects | Stolen or discarded media |
| Volume level | Encrypted block volume attached to an instance | Snapshot and media exposure |
| Object or file level | Each object encrypted, possibly by the client | Misconfigured storage access, provider staff |
| Database | Transparent database encryption or field level encryption | Theft of database files; field level also limits DBA viewing |
| Application level | The application encrypts before storing | Everyone without application access, including the provider |
| In transit | TLS 1.2 or 1.3 | Interception between components |
The higher the layer, the more threats are covered and the more work the customer does. Encryption performed by the provider with keys it controls does not protect against the provider.
Envelope encryption
Large data is encrypted with a data encryption key (DEK). The DEK is then encrypted with a key encryption key (KEK), often a master key held in a KMS or HSM. Only the wrapped DEK is stored with the data.
Rotating the KEK only requires rewrapping DEKs, not re-encrypting all data. Destroying the KEK makes every DEK under it, and so all the data, unreadable, which is how cryptographic erase works at scale.
Key management principles
- Separation: keys are stored and administered separately from the data and by different people.
- Least privilege: distinct permissions to administer keys and to use them for encryption.
- Rotation: on a schedule and after suspected compromise.
- Hardware protection: master keys in an HSM, ideally validated to FIPS 140-3.
- Backup and escrow: losing a key loses the data; archived data needs its keys kept as long as the data.
- Logging: every key use is logged for audit.
Hashing
A hash function produces a fixed length digest from any input. A small change in input changes the digest completely, and it is not feasible to recover the input or find two inputs with the same digest.
| Use | How |
|---|---|
| Data integrity | Compare the digest of stored or received data with a known good digest |
| Evidence integrity | Hash forensic images at acquisition and again before analysis |
| Password storage | Salted, slow password hashing functions, never plain fast hashes |
| Message authentication | HMAC combines a hash with a shared secret key |
Use SHA-2 or SHA-3 families. MD5 and SHA-1 are broken for collision resistance.
Non-repudiation
A plain hash proves integrity but not origin, because anyone can compute it. A digital signature hashes the data, then encrypts the hash with the signer's private key. Anyone can verify it with the public key, and only the holder of the private key could have created it.
HMAC does not give non-repudiation, because both parties share the key and either could have created the tag.
Keys, secrets and certificates management
| Item | Examples | Good practice |
|---|---|---|
| Keys | Encryption keys, signing keys | KMS or HSM, rotation, separation of duties |
| Secrets | Database passwords, API keys, tokens | Secrets manager, never in code or images, automatic rotation, short lifetimes |
| Certificates | TLS server certificates, client certificates | Inventory, automated renewal, monitored expiry, prompt revocation |
Secrets in source code repositories are a leading cause of cloud account compromise. Scan code and images for them in the pipeline.
Certificates are revoked through a certificate revocation list (CRL) or checked online with OCSP. An expired certificate causes an outage; a compromised one must be revoked and replaced.
A worked example
A SaaS company stores customer contracts in object storage with provider managed encryption. A large customer asks for assurance that provider staff and other tenants cannot read its contracts, and for the ability to cut off access at contract end.
The architect introduces per customer KEKs in an HSM backed KMS, with the customer able to disable its own key. Each document gets its own DEK, wrapped by that customer's KEK. Disabling the KEK at exit makes the documents unreadable, giving the customer verifiable crypto erase.
How the exam asks about this
- "Which technique provides non-repudiation for a document?" A digital signature using the sender's private key.
- "Why is envelope encryption used for large data sets in the cloud?" Data is encrypted with data keys protected by a master key, so rotation and revocation do not require re-encrypting everything.
- "Where should application database passwords be stored?" In a secrets manager with rotation, not in code or configuration files.
What to remember for the exam
- Encryption by the provider with its own keys does not protect against the provider.
- Envelope encryption: DEK encrypts data, KEK in a KMS or HSM encrypts the DEK.
- Hashing gives integrity; digital signatures add origin and non-repudiation.
- HMAC authenticates a message between parties sharing a key, without non-repudiation.
- Secrets belong in a secrets manager; certificates need inventory, renewal and revocation.
Losing a key is the same as losing the data. Archived data must keep its keys available for the full retention period, or it becomes unrecoverable.
Common mistakes
Treating hashing as encryption. A hash cannot be decrypted; it proves integrity, not confidentiality.
Thinking HMAC proves who sent a message. Both parties hold the key, so either could have produced it.
Leaving key administration and data access with the same person. One compromised account then exposes both the data and the means to read it.
Check yourself
What is the difference between a DEK and a KEK?
The DEK encrypts the data itself; the KEK encrypts, or wraps, the DEK and is usually held in a KMS or HSM.
Why does a plain hash not provide non-repudiation?
Anyone can compute a hash of the data, so it proves the data is unchanged but not who created it.
What is the main risk of hardcoding secrets in source code?
Anyone with access to the code or its history, including attackers who obtain it, can use the secrets to reach the systems they protect.
Topic 2 of 7 in Cloud Data Security
Test yourself on Cloud Data Security
The full ISC2 CCSP question bank has 900 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by ISC2. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.