CCSP Building Secure Cloud Infrastructure: HSM, TPM, Secure Defaults, Virtual Hardware and Guest Tools

A hardware security module is a dedicated, hardened and tamper-protected cryptographic device that generates, stores and uses keys inside its own protected boundary and offers those operations (sign, decrypt, wrap, unwrap) to many applications, usually over the network. A provider may offer HSMs as a dedicated single-tenant service or behind a multi-tenant key management service; either way, the property that matters is that the plaintext key never has to leave hardware.

Three configuration choices decide whether that property actually holds:

• Where the key is born. A key generated inside the module and marked non-extractable can be used but never exported in plaintext. A key generated on a workstation and imported, even wrapped, existed in plaintext outside the boundary, so nobody can prove it was not copied there.
• How it is backed up. A key that exists only in one module is lost when that module fails or is zeroized. HSMs back keys up as wrapped blobs: the key encrypted under a wrapping key that itself lives only in HSMs. A wrapped backup can be restored only into a module that holds the wrapping key, so whoever controls the wrapping key controls recovery. If the provider takes and holds that backup key, the customer no longer has sole control.
• How copies are kept. HSM clusters synchronize keys between members in wrapped form, so each member holds the keys inside its own boundary. Clustering adds availability; it does not, by itself, change who may export a key.

Controls that sound related do different jobs. Rotation limits how much data one key protects and how long it is in use; it does not stop export. Splitting a key into clear components under dual control is a real key-management practice, but those components are plaintext key material outside an HSM, which a "never in plaintext outside hardware" requirement forbids.

Tamper response and resilience

HSM physical security is about what happens when someone attacks the device itself. The vocabulary is graded:

Zeroization creates its own design requirement. If the only HSMs sit in one cage and a break-in triggers zeroization in all of them, the keys are gone. The resilient answer is another protected copy that the same incident cannot reach, such as a synchronized cluster member at a second site. The test for any recovery copy is two-fold: it must sit outside the reach of the incident that destroys the originals, and restoring it must never require the key to exist in plaintext outside an HSM.

Approved mode. FIPS 140-3 validates a module as described in its security policy, which lists the approved services and algorithms. Under FIPS 140-3 the module reports, per service, whether that service is approved (an approved service indicator); a non-approved service is not validated cryptography, and many HSMs enforce FIPS mode as a module-wide policy. When a contract requires that in-scope keys be used only through validated cryptography, the clean design keeps every in-scope key on a module running solely in approved mode and serves any legacy, non-approved need from a separate module that holds nothing in scope. Wrapping a key does not make the algorithm it is used with approved, and exporting a key to a software library is worse on both counts: the key leaves the validated boundary and the library is not the validated module. How to evaluate a FIPS 140-3 certificate or security level is covered with product certifications in sub-domain 1.5.

An HSM separates the people who administer the module from the identities that use keys. Vendors name the roles differently, but the CCSP-level model is:

An application that signs transactions authenticates as a crypto user. Giving it a crypto officer account, even one limited to a partition or protected by quorum, hands it administration it must never have.

Role separation does not stop one officer acting alone. That is what M-of-N quorum authentication does: N officers are enrolled and M of them must authenticate before a protected operation (restoring backups, changing policy, managing officers) proceeds. Multifactor authentication strengthens each login and logging records what happened, but neither prevents a single administrator completing the operation.

Sizing a quorum is simple arithmetic. M sets the minimum number of approvers. To keep operating when some officers are unavailable, N minus the number expected to be absent must still be at least M. For example, a rule of "at least three approvers, survive one absence" needs M = 3 and N = 4: with one officer away, three remain. Raising M without raising N breaks the absence rule, and enrolling more officers than the rule needs adds people who can take part in sensitive operations without adding resilience the business asked for. Plan quorum at initialization, before keys depend on the module; some modules fix it then, others let crypto officers change it later.

A trusted platform module is a hardware root of trust bound to one machine: it records measurements of that machine's boot, holds keys that only that platform can use, and can prove its identity and boot state to a remote verifier. Unlike an HSM it is not a shared service for other systems.

• Platform configuration registers (PCRs). As the server boots, each stage hashes the next (firmware, boot loader, hypervisor) and extends the hash into a PCR. A PCR cannot be written directly, only extended, so its final value summarises the whole chain. This is measured boot.
• Attestation. The TPM signs a quote of its PCR values with a key rooted in its endorsement key, its manufacturer-certified identity, so a remote party can check how the host booted. How a provider uses attestation to admit hosts into a cluster belongs with infrastructure design in Domain 3.
• Sealing. A key can be sealed to a policy of expected PCR values. The TPM releases it only when the current measurements match, so a disk key sealed to the approved boot chain unlocks automatically on an unaltered host and stays locked if any measured component changed. A key in TPM non-volatile memory behind a password is released to anyone with the password, whatever the platform's state.

The two complement each other; neither replaces the other. Sealing has an operational consequence: an approved firmware, boot loader or hypervisor update changes the measurements too, so the change procedure must reseal keys to the values expected after the update, or hosts will not unseal and boot unattended. The fix belongs in the change procedure: weakening another boot control does not restore the measurements, and the endorsement key is the TPM's identity, not part of the measured state that a sealed key depends on.

Virtual TPMs for guest VMs

A virtual TPM (vTPM) is a software TPM device that the hypervisor presents to one guest VM, giving the guest OS its own TPM for disk encryption, credential protection and its own measured boot. A host's physical TPM belongs to the host: it measures and protects the hypervisor and cannot be handed to many guests as each one's own TPM.

Three facts about vTPMs drive most build decisions:

• Its secrets live in the VM's files. vTPM state is stored with the VM, so the platform protects it by encrypting those VM files with keys from a key provider. A vTPM does not require a physical TPM in the host.
• The VM can only run where the key provider is reachable. If recovery-site hosts cannot obtain the keys that protect the vTPM state, replicated vTPM-equipped VMs will not power on, while VMs without a vTPM start normally. Disaster recovery plans must include key provider access, not just replicated disks.
• Cloning copies the vTPM. A clone of a VM with a configured vTPM carries the same endorsement and storage keys, so every clone presents the same identity and shares secrets. A TPM clear from inside the guest resets the storage hierarchy but leaves the endorsement key (and so the attestation identity) unchanged; only a newly generated vTPM gives each clone its own. Templates should be built without a provisioned vTPM, or each deployment should replace it.

Secure by default means a component arrives with its protective settings already on, so weakening them takes a deliberate, visible change. It describes the state a product or template is in out of the box, which makes it different from neighbouring ideas:

In practice, secure by default shows up in three build habits:

• Default deny. A virtual network template that every new environment starts from should allow no inbound traffic until a project explicitly opens what it needs. Even sensible rules (web ports, management from the corporate VPN) are project decisions, not template defaults. A provider's internal network is not a trusted source: it includes other tenants.
• No default credentials before exposure. A vendor image whose documentation publishes the first admin login is open to anyone who reads it. Setting a unique administrator credential and binding the management console to the management interface comes first, before production interfaces are connected, before reaching update services and before registration with central tools.
• Only needed services on. Management interfaces, shells and host-to-guest features that are not required should be off in the template rather than disabled later by whoever remembers.

Secure by default is a build-time property. Keeping components at their baseline afterwards (OS hardening, patching, monitoring) is the operate-and-maintain work of sub-domain 5.2.

Management plane tools (the virtualization management server, orchestration and monitoring tools, appliance consoles) control every workload beneath them, so a compromised installer or over-privileged account compromises the whole environment. Installing them securely starts with proving the software is genuine.

A stronger hash algorithm does not help when the attacker controls where the hash is published. Install onto the dedicated management network, not a network shared with workloads.

Configuration then decides who and what can act:

• Replace the installer's self-signed TLS certificate with one issued by the organization's trusted CA, so browsers and API clients validate the server and a certificate warning means a real interception attempt. Telling administrators to click through warnings, or adding self-signed certificates to each browser, trains them to ignore the signal.
• Federate people. Connect administrator sign-in to the corporate identity provider with MFA so access is attributable and centrally revocable.
• Keep one break-glass account. The local superuser the installer created should be vaulted and alarmed on every use, so administrators can regain access if the identity provider fails. The account has to be usable at the moment federation is unavailable, without depending on anyone signing in through federation first, and it must stay reserved for emergencies so that every use is an event worth investigating.
• Give automation its own identity. A pipeline or tool should authenticate with a dedicated service account, attributable and revocable without affecting people, and with a role scoped to its task. A monitoring tool that only reads inventory and performance gets a read-only role; a pipeline that creates VMs in one cluster gets a custom role on that cluster. Rotation, source-address limits and alerts are useful additions, but they do not shrink what a stolen credential can do.

A virtual switch enforces three per-port-group security settings that decide what a guest's virtual NIC may receive and send. Each should be set to reject unless a workload has a documented need:

The near-twins are tested together: forged transmits guards what a VM sends, MAC address changes guards what it receives, and impersonation that combines both needs both rejected. VLAN tagging and trunking separate broadcast domains; they do not check MAC addresses within a segment. Traffic shaping limits bandwidth only.

Scope exceptions narrowly. Some workloads legitimately need relaxed settings; nested hypervisors running as VMs, for example, need promiscuous mode and forged transmits allowed (or a MAC-learning feature) so their own VMs get network access. Settings are inherited from the switch-wide default and can be overridden per port group, so the safe pattern is a new port group used only by those hosts, never a relaxed switch default or a port group shared with other VMs.

Memory and CPU settings trade consolidation and performance against isolation between tenants. Each setting creates a specific exposure, and the control must match it.

Memory

• Transparent page sharing between VMs deduplicates identical pages across guests. Research showed it opens a timing side channel through which one VM can infer another's data, so modern hypervisors restrict sharing to pages within a single VM by default. A multi-tenant build should keep inter-VM sharing disabled.
• Ballooning reclaims memory through a driver in the guest toolset, letting the guest decide what to page to its own disk. It merges nothing across VMs.
• Overcommit with hypervisor swapping writes guest pages, including any secrets in memory, to a per-VM swap file on storage. Encrypting the swap file (part of hypervisor VM encryption) keeps that copy unreadable; restricting datastore access is a weaker control because storage administrators, backups and replicas still see it in clear.
• A full memory reservation stops the hypervisor swapping that VM at all, because the host swap file only covers configured memory minus the reservation. When a policy forbids guest pages ever reaching storage, a full reservation for that VM meets it without disabling overcommit for the rest of the cluster; encryption or moving the swap file to local flash still writes pages to a disk.

CPU

Simultaneous multithreading (SMT) exposes two hardware threads per physical core that share caches and execution units, so a flaw can let code on one thread read data used by its sibling. The configuration depends on what the business will accept:

Encryption only hides data from layers below the point where it is applied, because each layer hands decrypted data to the layer above. Choosing where to encrypt, and who holds the keys, therefore answers the question "whose administrators must see only ciphertext?"

Two consequences follow. First, switching hypervisor encryption to a customer-managed key changes who controls the key, but the hypervisor still decrypts blocks, so provider administrators with hypervisor access are not excluded; only encryption inside the guest with keys the provider never holds does that. Key rotation changes neither layer. Second, data read out through the hypervisor leaves decrypted: a backup product that reads VM disks through the hypervisor's backup API receives plaintext, so the backup tool or repository must encrypt the copies with its own managed keys. Excluding encrypted VMs from backup removes the exposure but also the ability to recover them. Transport protections (TLS on the storage network, encrypted array replication) protect data in transit, not the files at rest.

A type 1 (bare-metal) hypervisor runs directly on the hardware; a type 2 (hosted) hypervisor runs as an application on a general-purpose operating system. Why type 1 has the smaller attack surface is covered in sub-domain 1.3; what 5.1 adds is what each type requires at build time.

On a type 1 host, a policy that day-to-day administration go only through the central management server is met by closing the other paths: disable the shell services and enable the host's lockdown mode, leaving direct access only for named exception accounts. Controls that only make the direct path harder to use or easier to observe leave it open, and anything installed in the host shell adds code to the layer the build is trying to keep small.

When extra software is needed on the same server (monitoring, backup), the way to keep the privileged layer small is a bare-metal hypervisor with that tool stack in its own management VM. Installing tools in the hypervisor's shell grows exactly the layer to minimise, and any hosted design keeps a general-purpose host OS in the privileged layer beneath every guest.

A guest OS virtualization toolset is the vendor package installed inside each VM that provides paravirtual (optimised) storage and network drivers, time synchronization with the host, graceful shutdown, heartbeat and snapshot quiescing, and a host-to-guest channel that management tools use. It does not isolate memory (the hypervisor and CPU do that), encrypt virtual disks or filter traffic between VMs (the virtual switch or a distributed firewall does).

Installing it securely means:

• Trusted source and matching version. Install the toolset from the hypervisor vendor's own distribution or the OS vendor's packaged version, verified like any other software, and keep it in step with the hypervisor version so drivers and fixes match.
• Keep what is needed, turn off what is not. Removing the toolset entirely loses the drivers and time sync and, with ballooning gone, can push the hypervisor to swap guest memory to its own swap file instead. The better control is to disable the specific host-to-guest features the workload does not need.

The two transfer paths are separate settings. Disabling the guest operations interface does not stop console clipboard transfer, and VM encryption does not stop it either, because data copied through the console is already decrypted.