2.2 Data Protection and KMS

Data Protection and KMS

Data-protection scenarios usually open with a requirement: audit key usage, meet an encryption-at-rest policy, avoid hardcoded secrets, or protect object and database data. Key Management Service (KMS) is the central cryptographic key-lifecycle service on Alibaba Cloud.

Customer master keys and key ownership

A customer master key (CMK) sits at the top of the hierarchy. Its key material never leaves the KMS service boundary and is never exported in plaintext — a CMK is used to protect data keys, not to encrypt large application payloads directly. KMS supports software-protected and hardware-protected (HSM) CMKs; choose hardware-protected when compliance demands FIPS-validated hardware.

Key ownership is the most-tested distinction:

When a question stresses explicit ownership, rotation control, access policy, or auditability, the answer is a user-managed CMK, not a service-managed key. When it requires customer-supplied key material, the answer is Bring Your Own Key (BYOK).

Envelope encryption flow

Envelope encryption is a guaranteed exam topic. The order of operations is the trap, so memorize it:

1. The application calls KMS GenerateDataKey, which returns a plaintext data key and an encrypted (wrapped) data key.
2. The application encrypts the bulk data locally with the plaintext data key.
3. The application discards the plaintext data key from memory and stores the encrypted data key alongside the ciphertext.
4. To decrypt, the application sends the encrypted data key to KMS Decrypt; the CMK unwraps it and returns the plaintext data key for in-memory use only.

This design keeps large payloads off the network (you never send bulk data to KMS) while the CMK material stays inside KMS. The wrong-answer trap claims the master key is stored beside the ciphertext — it never is; only the encrypted data key is.

Service integrations

For OSS, prefer SSE-KMS when the question mentions KMS keys, RAM permissions on key use, or ActionTrail evidence for decrypt operations; SSE-OSS is fine only when no key control is required. For RDS, Transparent Data Encryption (TDE) is chosen when the application must keep running unchanged while storage stays encrypted under KMS-backed keys. For credentials, KMS Secrets Manager stores and rotates secrets so nothing is hardcoded.

Choosing the right model: a worked example

A fintech app must store scanned ID documents in OSS, run a regulated database in RDS, and connect to a third-party payment API. Map each requirement:

• ID documents in OSS — auditors want proof of every decrypt and customer-controlled permissions, so use SSE-KMS with a user-managed CMK. Decrypt calls then appear in ActionTrail, and a RAM policy can restrict which role may use the key.
• RDS regulated data — enable TDE so data files, redo logs, and backups are encrypted at rest under a KMS key with zero application changes.
• Payment API token — store it in Secrets Manager with scheduled rotation rather than in an environment variable or config file.

Key rotation, deletion, and separation of duties

The exam likes the difference between disabling and scheduling deletion of a CMK. Disabling is reversible and immediately blocks all crypto operations; scheduled deletion enforces a mandatory waiting period (you cannot delete a CMK instantly) so accidental loss of access to ciphertext is preventable. Automatic rotation generates new backing key material on a schedule while keeping the same key ID, so existing ciphertext still decrypts.

Separation of duties is enforced through RAM: the team that uses a key (kms:Decrypt) should differ from the team that administers it (kms:ScheduleKeyDeletion, kms:DisableKey). A common trap answer hands one role both bulk-data access and key-deletion rights — reject it.

Finally, remember the layered boundary: KMS protects data at rest and in the key layer; it does not replace Transport Layer Security (TLS) for data in transit, nor does it substitute for access controls. A complete answer pairs KMS encryption with HTTPS/TLS and least-privilege RAM policies.