Data Protection & Privacy in Cloud
Encryption • Secure Storage • GDPR / HIPAA • Anonymization
Why data protection matters (and what you will build)
Real-world goal Typical mistakes (seen in internships)
Build a secure “file upload + storage” pipeline that: 1) Bucket/container made public “for testing”
• Encrypts data at rest and in transit 2) Encryption turned off or unknown
• Uses managed keys (KMS/Key Vault/Cloud KMS) 3) Secrets hardcoded in code / .env
• Prevents public access misconfigurations 4) No rotation of keys
• Logs access (audit trail) 5) No logs → cannot investigate incidents
• Supports privacy (minimize + anonymize where needed)
Mini-lab roadmap (90 minutes)
A) Create a storage bucket/container (private)
B) Turn on default encryption with a managed key (CMK/CMEK)
C) Upload using a time-limited URL/token (pre-signed URL / SAS)
D) Verify: public access prevention + audit logs + key usage logs
Encryption basics (practical view)
Data in transit (network) Data at rest (stored)
• Use TLS (HTTPS) between client <-> server <-> storage • Encrypt files/objects on disk
• Protects against sniffing / MITM • Cloud storage supports server-side encryption (SSE)
• Verify certificates + disable weak ciphers • Option: customer-managed keys for control & audit
Envelope encryption (how KMS works)
Plaintext
(File / Record) → Data Key
(AES) → Encrypted Data
(ciphertext) → Encrypted Data Key
(wrapped by KMS key)
Idea: encrypt data locally with a data key; then protect that data key by encrypting it with a long-term KMS key.
Key management services (KMS/Key Vault/Cloud KMS)
What they do (in one line): create keys, control who can use them, rotate/disable them, and log key usage.
AWS KMS Azure Key Vault Google Cloud KMS
Best for: encrypting AWS data services Stores: secrets, keys, certificates Best for: CMEK (customer-managed keys)
Practical features: Practical features: Practical features:
• KMS keys + data keys • RBAC / access policies • Key rings + keys
• IAM policies control usage • HSM-backed options • IAM controls key usage
• Audit via CloudTrail • Managed identities avoid hardcoded secrets • Audit logs in Cloud Logging
• Integrates with S3, RDS, EBS… • Logging to Azure Monitor • Integrates with Cloud Storage, BigQuery…
Key management services (KMS/Key Vault/Cloud KMS)
What they do (in one line): create keys, control who can use them, rotate/disable them, and log key usage.
Dimension AWS KMS Azure Key Vault Google Cloud KMS
Main focus Keys for encryption/signing Keys + Secrets + Certificates Keys for encryption/signing
KeyRing → CryptoKey → versions (Google Cloud
How you organize keys KMS keys (regional); policies/grants Vault (or Managed HSM) contains objects
Documentation)
Key policies + IAM + grants; audited in CloudTrail Azure RBAC / access model; vault-level controls IAM roles per key/keyring/project (Google Cloud
Access control model
(AWS Documentation) (Microsoft Learn) Documentation)
Customer-managed symmetric keys: automatic
Rotation supported; plus strong recovery controls Rotation schedules; key versions lifecycle (Google
Rotation rotation (configurable); AWS-managed rotate
(soft delete/purge protection) (Microsoft Learn) Cloud Documentation)
yearly (AWS Documentation)
CloudTrail logs for KMS API calls (AWS Diagnostic logs to Azure Monitor/Log Analytics Cloud Audit Logs for KMS activities (Google Cloud
Logging/audit
Documentation) (Microsoft Learn) Documentation)
Built in (secrets are first-class objects) (Microsoft
“Secrets” storage Use Secrets Manager (separate service) Use Secret Manager (separate service)
Learn)
Encrypt data in AWS services (S3/EBS/RDS etc.) Central “vault” for app secrets + keys + certs; great CMEK-style key control across GCP services; strong
Best fit in real projects
with customer-managed keys; strict audit trail for app configuration/security org/IAM integration
Mini-demo: envelope encryption in practice
Scenario
You want to encrypt a 50 MB file before storing it in cloud object storage.
Do NOT send the whole file to KMS. Instead:
Steps (cloud-agnostic) Pseudo-code
1) Request a data key from KMS (returns plaintext + encrypted copy)
2) Encrypt file locally with plaintext data key (AES) dk = [Link](keyId)
3) Store: (encrypted file) + (encrypted data key) ciphertext = AES_Encrypt(fileBytes, [Link])
4) To decrypt: send encrypted data key to KMS → get plaintext key → decrypt file store(ciphertext, [Link])
dk2 = [Link]([Link])
fileBytes = AES_Decrypt(ciphertext, [Link])
AWS practical: S3 + KMS (SSE-KMS)
What to configure AWS CLI (concept)
• Bucket: keep private + enable “Block Public Access”
• Default encryption: SSE-KMS # C reate a custo m er- m anag ed K M S key (C M K )
• IAM: allow app role to “PutObject/GetObject” aws kms create-key
• KMS key policy: allow usage (encrypt/decrypt) only for app role
# Enable default SSE-KMS on a bucket
aws s3api put-bucket-encryption --bucket <B> --server-side-encryption-configuration ...
# Upload (S3 encrypts using KMS)
aws s3 cp [Link] s3://<B>/[Link]
Verification checklist (students must show in lab report)
Bucket is not public (Block Public Access enabled)
Default encryption is SSE-KMS (not “None”)
KMS key has rotation policy (if required)
Audit trail: CloudTrail shows who used the key / accessed bucket
Azure practical: Blob Storage + Key Vault
What to configure Azure CLI (concept)
• Storage account: disable anonymous blob access
• Encryption at rest: Storage Service Encryption (SSE) # C reate a K ey Vault + key
• For extra control: customer-managed key in Key Vault az keyvault create -n <KV> -g <RG>
az keyvault key create --vault-name <KV> -n cmk --protection software
• Access: Azure AD RBAC + Managed Identity (avoid secrets)
# Storage encryption (SSE) is on by default; configure CMK if required
# Prefer Managed Identity for apps accessing storage
Verification checklist
Anonymous blob access is disabled at account level
Encryption at rest (SSE) enabled
App uses Managed Identity + RBAC (no hardcoded secrets)
Key Vault logging enabled (audit key access)
Google Cloud practical: Cloud Storage + Cloud KMS (CMEK)
What to configure gcloud (concept)
• Bucket: enforce Public Access Prevention
• Default encryption: Google-managed by default # C reate key ring + key
gcloud kms keyrings create <KR> --location=<LOC>
• For extra control: CMEK using Cloud KMS
gcloud kms keys create cmek --keyring=<KR> --location=<LOC> --purpose=encryption
• IAM: grant key usage only to service account used by your app
# Set bucket default CMEK
gcloud storage buckets update gs://<B> --default-encryption-
key=projects/.../cryptoKeys/cmek
Verification checklist
Public Access Prevention is enforced
Bucket uses default encryption key (CMEK if required)
Audit logs show KMS key usage
Service account permissions are minimal (least privilege)
Secure data storage (S3 / Blob / Cloud Storage): checklist
1) Prevent accidental public access
AWS: Block Public Access • Azure: disable anonymous blob access • GCP: Public Access Prevention
Access control Encryption + keys Durability + recovery
• Least privilege roles • Default encryption ON • Versioning
• No shared accounts • Use CMK/CMEK when needed • Immutability / WORM (Object Lock)
• Short-lived access (SAS / pre-signed URLs) • Rotate keys (policy-driven) • Lifecycle policies
• Separate dev/test/prod buckets • Separate duties (use vs admin) • Backup critical data
Privacy regulations (engineer’s view): GDPR & HIPAA
GDPR (EU) — key ideas HIPAA (US) — key ideas
Applies when processing personal data of people in the EU. Applies to protected health information (PHI) handled by regulated entities.
Engineering takeaways: Engineering takeaways:
• Data minimization (collect only what you need) • Safeguards: administrative, physical, technical
• Purpose limitation (use only for stated purpose) • Focus: confidentiality, integrity, availability
• Security of processing (encryption + access control) • Access controls + audit controls
• Rights: access, erase, rectify (need data inventory) • Encrypt PHI in transit + at rest
Privacy-by-design (practical techniques)
Design moves that reduce privacy risk
In your API & database In cloud storage
• Collect minimum fields (no “nice to have” PII) • Store PII in a dedicated bucket/container
• Separate identifiers from sensitive attributes • Strict IAM + no public access
• Encrypt sensitive columns/records • Use time-limited uploads/downloads
• Access logs: who read which record • Tokenize filenames/paths (avoid names in URLs)
• Retention policy: auto-delete old data • Enable versioning + immutability if needed
Anonymization & privacy preservation (with examples)
Pseudonymization vs anonymization Common techniques (engineering)
Pseudonymization: replace identifiers but keep a mapping separately (reversible with • Masking (hide part of value)
extra info). • Tokenization (replace with random token)
Anonymization: transform data so individuals are not identifiable (harder; risk- • Hashing + salt (for matching, not secrecy)
based). • Generalization (age → age band)
• k-anonymity / differential privacy (advanced)
Mini example: anonymize a student dataset for analytics
Field Before After (privacy-preserving)
Name "Riya Sharma" Token: U-8F2A9C
Phone 9876543210 Mask: 98******10
DOB 2004-03-21 Age band: 18–21
College ABC Institute Generalize: Tier-2
Case study + quick quiz
Case: “Public bucket leak” (common pattern) Quick quiz (5 mins)
Symptom:
• Someone shares a storage URL; files become accessible publicly 1) Why is CMK/CMEK useful beyond encryption?
2) Give one safe alternative to “public bucket for sharing”.
Root causes: 3) What logs help you prove who accessed a file?
• Public access enabled (bucket policy / ACL / anonymous access) 4) Pseudonymization vs anonymization (1 line each).
• No guardrails (public access prevention) 5) Name one GDPR principle that changes DB design.
Fix (order matters): Expected answers (brief):
1) Block public access immediately kill switch + audit; pre-signed URL/SAS; audit/flow logs; reversible vs not;
2) Rotate exposed credentials/tokens minimization/purpose limitation.
3) Review logs (who accessed what)
4) Add preventive policies (deny public)
5) Add default encryption + key auditing