Cloud Data Security

The correct methodology involves contextual analysis leveraging system metadata and object tagging.

Because the data is encrypted on the client side before being uploaded to the cloud, the cloud provider and any third-party discovery tools cannot inspect the actual content (payload) of the files. The data is effectively opaque. In this scenario, the only available information for classification is external attributes associated with the objects.

Contextual analysis examines these attributes, which include:

1. Metadata: Standard system information such as creation date, file size, owner ID, and bucket or container names. For example, if a bucket is named 'finance-archive-2023', the department and basic retention context can be inferred.
2. Tags: Key-value pairs applied to the object (e.g., 'Project: Alpha', 'Dept: HR').

By analyzing where the data is stored (folder paths), who owns it, and how it is tagged, the governance team can build an inventory without needing to decrypt the contents.

Why the other answers are incorrect:

• Signature matching against cleartext binary header segments: Client-side encryption typically encapsulates the entire file, including file headers, within the encrypted blob. There would be no cleartext headers available for signature matching.
• Homomorphic profiling of the persistent ciphertext structures: Standard client-side encryption (like AES) does not support homomorphic operations. Homomorphic encryption is a specialized use case not implied here, and 'profiling' ciphertext structures to determine semantic classifications like 'department' is technically infeasible for standard governance data discovery.
• Statistical sampling of traffic flows: This technique analyzes data in motion (network traffic), whereas the question specifically asks about creating an inventory for 'existing archives' (data at rest). Furthermore, traffic flow analysis rarely provides the granular semantic detail required for retention policy classification.

The architecture relies on hardware trust principles to separate the guest application from the underlying infrastructure. The process begins with the Trusted Execution Environment (TEE), or enclave, generating a cryptographic quote. This quote serves as proof of the enclave's identity and measuring the software running inside it, signed by the hardware root of trust. When the enclave requests the DEK, it sends this quote to the Key Management Service (KMS). The KMS validates the attestation to ensure the request is coming from a genuine, unmodified enclave. Crucially, the quote includes a fresh public key generated inside the enclave. The KMS wraps (encrypts) the requested DEK with this specific public key. Because the corresponding private key never leaves the secure enclave, neither the host operating system nor the hypervisor can decrypt or inspect the DEK while it is in transit or being processed by the host stack.

Other options fail to address the specific constraint of shielding data from the host OS/hypervisor during the delivery phase:

• Relying solely on a hardware-isolated TLS tunnel is insufficient because, in many architectures, the TLS termination point or the network stack might still expose decrypted traffic to the kernel or hypervisor before it reaches the enclave memory space, or the host could simply act as a man-in-the-middle if attestation isn't bound to the session keys.
• Confirming identity and injecting into a protected memory page describes a mechanism often used in virtualization, but it implies the hypervisor is trusted to perform the injection. The goal here is to assume the hypervisor is untrusted, requiring cryptographic wrapping that bypasses the hypervisor's ability to read the data.
• Creating a session-specific symmetric key without tying it to the hardware attestation process leaves the key exchange vulnerable to interception or manipulation by the host OS, which could spoof the application.

The correct answer is: The original data stays in the local vault, ensuring only surrogate values cross the jurisdictional boundary.

The fundamental distinction between tokenization and encryption in the context of data residency is the relationship between the sensitive data and the data sent to the cloud.

In a tokenization model, the sensitive data (e.g., PII) is swapped for a random, non-mathematically derived token (surrogate) within a secure, local vault. The sensitive data remains physically within the local jurisdiction and never leaves the premise. Only the token, which has no mathematical relationship to the original data, crosses the boundary into the global SaaS platform. Because the cloud provider only receives a placeholder with no intrinsic value or way to derive the original data without the vault mapping, strict data residency requirements are satisfied by preventing the data from ever entering the foreign jurisdiction.

By contrast, with client-side encryption, the actual data is obfuscated via a mathematical algorithm and sent to the cloud. While the keys are kept locally, the encrypted ciphertext (which contains the original information in a transformed state) physically resides in the cloud environment. Some strict jurisdictions may view the export of encrypted data as still being an export of the data itself.

Why the other answers are incorrect:

• Retaining encryption keys in a local HSM describes a feature of client-side encryption or specific key management strategies (like BYOK/HYOK), not the distinguishing factor of tokenization. In encryption, the ciphertext still moves to the cloud.
• Maintaining the original data structure (Format Preserving encryption or tokenization) is a feature that ensures application compatibility, but it applies to both advanced encryption schemes and tokenization. It does not distinguish the fundamental mechanism of residence.
• Employing a reversible algorithm applies to encryption. Tokenization is generally non-algorithmic (it uses a look-up table/vault), meaning the relationship is arbitrary rather than mathematical.