CCSP Cloud Infrastructure and Platform Components Explained

In public cloud the provider owns and secures the physical environment under every service model: the buildings, perimeter, power, cooling, fire suppression, racks, host servers, network hardware and storage media. Shared responsibility moves up and down the stack with IaaS, PaaS and SaaS, but in public cloud the facilities and the host hardware always stay with the provider. A typical IaaS customer is responsible for the guest operating system and everything above it, not for the server that guest runs on.

Colocation rents space, power, cooling and building security; the tenant still owns, installs and maintains its servers. IaaS adds the host hardware and, for standard virtual machines, the hypervisor to the provider's side. The exception is a bare-metal server: the provider still owns the machine, its firmware and the facility, but supplies no hypervisor, so a customer that wants one installs and runs it (see the compute isolation section).

Assurance without site visits

Providers do not let each tenant inspect shared facilities, so customers rely on independent attestations:

• SOC 2 Type II reports on the security (and other selected) trust services criteria, including physical access, and tests whether controls operated effectively over a review period. This is the report to rely on for operating effectiveness.
• SOC 2 Type I covers only the design of controls at a point in time.
• SOC 3 is a short general-use summary of the same examination, without the detailed description of controls and tests that a SOC 2 report gives its restricted readers.
• ISO/IEC 27001 certification (with the cloud controls of ISO/IEC 27017) shows a managed security programme is in place.

Every report is bounded by its scope: the services, locations and period the auditor examined. Its opinion says nothing about anything outside that boundary. Suppose a provider's report covers its compute and storage services but not a newly launched managed database: the customer either keeps sensitive workloads on the covered services or obtains other evidence for the new one (contractual audit rights, the provider's next report once scope widens). A bridge letter (gap letter) is a management assertion from the provider covering the interval between the end of the last report period and today. It extends coverage in time, and it never adds systems or sites the auditor did not examine.

Below the hypervisor sit the host's hardware and firmware, and two components there decide whether everything above can be trusted: the baseboard management controller (BMC) and the Trusted Platform Module (TPM).

A BMC is an out-of-band management controller with its own processor and network interface. It lets operators power-cycle the host, view its console, mount virtual media and update firmware over the network, even when the operating system or hypervisor is down. Because it works independently of the hypervisor, an attacker who reaches a BMC bypasses every hypervisor control, however well hardened. The root-cause control is network isolation: BMCs belong on a dedicated, restricted management network that tenant workloads cannot reach. As with any management interface, reachability is the first decision: hardening the controller's own login and sessions is good defence in depth, but it does not change who can send packets to it.

Secure boot versus measured boot

Attestation needs a maintained baseline of expected values. An approved firmware or hypervisor update legitimately changes the measurements, so the baseline is updated for the hosts in that change. A host that fails attestation without an approved change is a possible tampering signal: it stays out of scheduling (quarantined) and is investigated. Only a measurement chain rooted in hardware and starting at the first boot instruction can vouch for firmware and hypervisor: anything that starts later could itself have been loaded by tampered code.

That rules out tools that work at other layers, however useful they are there. Security agents inside guest operating systems, such as file integrity monitoring, run on top of the hypervisor: they see only the guest's own files, cannot observe host firmware or the boot loader, and would report normally on a compromised hypervisor that hides itself from them. A hardware security module protects cryptographic keys and performs operations with them; it holds secrets for workloads but takes no measurements of the server it is attached to. Host integrity is a property the host's own hardware root of trust has to report, which is the TPM's job.

Software-defined networking (SDN) separates the network's decision-making from its forwarding. The control plane is a central SDN controller that decides how traffic should flow and programs the forwarding devices; the data plane is the physical and virtual switches that forward packets according to the flow tables the controller installs. Orchestration tools reach the controller through a northbound API; the controller programs switches through a southbound protocol.

Cloud networks provide the usual functions (address allocation, routing, access control and filtering, bandwidth allocation and rate limiting) but deliver them in software, per tenant, on demand. That centralization is SDN's strength and its main risk: the controller and the API that drives it become a single point of compromise for every tenant segment, and a single point of failure for network change. Any one switch, virtual or physical, affects only the traffic passing through it.

Each interface needs its own control. Northbound controls decide who may ask the controller for changes; southbound authentication decides which device the switches will take instructions from. Likewise, redundancy answers failure while isolation, individual authentication and attribution answer compromise, so a design meant to address both concerns needs both kinds of control.

Clouds isolate tenants at layer 2 with segment identifiers, and isolate their own infrastructure traffic by keeping each traffic type on its own network.

VLANs versus VXLAN overlays

Large multi-tenant clouds exhaust VLAN IDs, which is why they use overlays. Many network controls sound like segmentation but solve a different problem, and none of them enlarges the identifier space:

Filtering and admission controls are valuable inside or between segments, but only a larger identifier space creates more segments. Two limits of overlays matter for security:

• Separation is not confidentiality. Anyone tapping the physical network can read the inner frames, so confidentiality on shared links needs encryption in transit (IPsec between hosts or TLS in the workloads). The same is true of any segmentation technique: a VLAN tag is just as readable.
• Segments trust the identifier. An overlay delivers a packet to whichever segment its identifier names, so a device on the underlay that can send crafted tunnel packets can inject into another tenant's segment. The control belongs on the underlay: only authorized tunnel endpoints may send tunnel traffic, enforced with access control and, where needed, IPsec between endpoints. An identifier is a label, not a secret: the segment boundary depends on controlling who can send labelled traffic.

Separate networks for each infrastructure traffic type

Hosts carry four kinds of traffic with different trust levels: host management (controls the hosts), live migration (carries VM memory), storage (carries disk data) and tenant VM traffic (the least trusted). Good practice puts each on its own isolated network, physical or logical, so a compromised workload cannot reach the others and a busy flow cannot starve them. The main risk that management-network isolation addresses is a tenant VM reaching and attacking host management interfaces.

When hardware limits how many uplinks each host has, separation is done logically: a separate VLAN per traffic type, quality of service to guarantee storage and migration bandwidth, and access rules restricting the management segment, with the uplinks teamed for redundancy. The design goal has two parts, each traffic type on its own network and no single link failure taking a type down, and logical separation over teamed links meets both.

Virtualization lets one physical host run many isolated virtual machines under a hypervisor. A Type 1 (bare-metal) hypervisor runs directly on the hardware and is what cloud providers use; a Type 2 (hosted) hypervisor runs as an application on a host operating system, which adds that operating system to the attack surface. Containers are a lighter form of isolation in which workloads share the host's kernel. The hypervisor is the isolation boundary between tenants, so its integrity (and that of the host beneath it) underpins every tenant's security.

Each host runs a virtual switch that connects its guests' virtual network interfaces. When two VMs on the same host and the same virtual network talk, their frames are delivered in memory inside the virtual switch; they never cross a physical cable, reach a top-of-rack switch, pass through the SDN controller or reach the edge firewall.

That has a direct security consequence: sensors and firewalls on the physical network cannot see intra-host traffic. No tuning or repositioning of a physical sensor changes this, because the packets never reach it. Inspection and filtering must happen at the virtual layer:

• a distributed firewall enforced at each VM's virtual network interface, which follows the VM wherever it runs;
• virtual IDS/IPS appliances or hypervisor-level traffic mirroring;
• micro-segmentation rules by application tier.

The same reasoning applies to any device on a routed path: it sees traffic only when the traffic leaves the segment, so filtering between VMs on one virtual network has to be enforced at each VM's own interface.

Compute in a shared pool is allocated with three controls, and the exam expects you to tell them apart precisely:

These controls are how a provider manages noisy neighbours and protects availability. Worked examples:

• A build server must always get at least 2 vCPUs' worth of CPU time, whatever else the cluster is doing. That is a floor, and only a reservation creates one.
• A production tenant and a development tenant share a cluster. Production must win whenever both are busy, but development should be free to use whatever production leaves idle at night. Giving production higher shares does exactly that: shares cost nothing when there is no contention, which is what separates them from a ceiling.
• Admission control powers on a VM only if its reservation fits in unreserved capacity. A reservation counts as committed whether or not the guest touches it, so reservations sized above a VM's true minimum shrink the pool available to everything else. Shares and limits are not checked at power-on.

Beyond standard shared multi-tenant VMs, providers offer three stronger isolation options, and each answers a different threat:

Nested virtualization is sometimes mistaken for a fourth option. It lets a customer run its own hypervisor inside a provider VM, which suits test labs, training environments and emulators. The provider's hypervisor is still underneath, so nested virtualization offers no isolation from the provider layer and no direct access to the hardware; it is a convenience feature, not an alternative to bare metal.

Choose by the threat named, with the least change that removes it:

• A software licence or contract forbids sharing physical servers with other customers: the threat is physical co-tenancy, so dedicated hosts.
• A security team must run its own hypervisor-level forensics or a kernel that cannot run as a guest: the requirement is no provider virtualization layer, so bare metal.
• A data-processing agreement says decrypted data in memory must be inaccessible to the provider: the threat is to data in use, so confidential VMs.

Map every control to the data state or boundary it protects: encryption at rest protects stored data, encryption in transit protects data on the wire, accounts and virtual networks separate tenants logically, dedicated hardware separates them physically, and only a hardware trusted execution environment protects data while it is processed. When a threat model names several of these, combine the matching options.

Live migration moves a running VM between hosts by iteratively copying its memory pages over the network, then pausing briefly to transfer the final state. That memory holds encryption keys, credentials and data being processed in the clear. On a shared, unencrypted network, anyone who can sniff the traffic captures it. The controls are an isolated migration network and encrypted migration traffic, which most hypervisors support on existing hardware. Migration exposes memory in transit, so the protection has to apply to the migration stream itself.

Automatic migration places VMs by load, not by compliance scope, so regulated VMs can drift onto hosts that were never assessed. Placement is a scheduling problem: host-group or affinity rules tell the scheduler which hosts a VM may run on, so automation keeps balancing load inside the approved boundary.

VM sprawl and dormant VMs

VM sprawl happens when self-service provisioning creates machines faster than they are tracked. The first step is discovery: an inventory of every VM, running or powered off, with an owner and purpose. Every later step depends on knowing what exists, whether it is running, and who can decide its fate, so inventory and ownership come first.

Dormant VMs, images and templates receive no patches, signature updates or configuration changes while powered off. When started they are as old as their last update and can be exploited before normal patching reaches them. The controls make images current before they run: patch and scan offline images before they rejoin the network (or start them on an isolated network until current), and rebuild, patch and scan golden templates on a regular schedule. Controls that act after a VM boots shorten the exposure window; refreshing the source image removes it.

Cloud storage is built from clusters of storage nodes, and the CCSP distinguishes two designs:

Large, unpredictable growth with small failure impact points to loosely coupled; high performance in a fixed-size pool points to tightly coupled.

On top of these clusters, IaaS offers volume (block) storage attached to VMs and object storage accessed through APIs; PaaS offers structured (database) and unstructured (blob or file) storage; SaaS offers information storage and management inside the application and content and file storage.

Protecting storage networks

Each storage network control answers one question: which ports can see each other (zoning), which LUNs a connected host is shown (masking), which devices may join (authentication and port security), or whether storage stays reachable (multipathing). A gap in one is not closed by strengthening another.

• Fibre Channel zoning, configured on the fabric switches, decides which host and storage ports can see each other at all (by port or WWN). Use it when hosts must not even discover another cluster's storage ports.
• LUN masking, configured on the array (or host), decides which logical units each initiator that can reach an array port is shown. The two layer: zoning decides which ports may talk, masking decides which LUNs an initiator sees behind a port it is legitimately allowed to reach.
• Fabric authentication and port security answer a different question: who may join. Fibre Channel Security Protocols (FC-SP) define DH-CHAP so a switch and a device authenticate each other at fabric login, and port security (binding a WWN to a specific switch port) stops a device from impersonating another host's WWN on a different port. Once a host has legitimately logged in, neither control decides which ports it can reach or which LUNs it is shown: that is still zoning and masking.
• Multipathing gives each host redundant paths, often through two separate fabrics, so a failed switch, cable or adapter does not cut it off from storage. It is an availability control and restricts nothing.
• iSCSI carries block storage over ordinary IP networks, so anyone who can reach the network can try to connect to targets or read traffic. Protect it with an isolated storage network or VLAN, CHAP authentication of initiators, and IPsec where encryption is required. Zoning is a Fibre Channel fabric concept; on IP storage the equivalent separation is a dedicated storage network or VLAN.

The management plane provides centralized administration of the cloud infrastructure: provisioning, scheduling, orchestration, configuration, monitoring and maintenance across hosts, networks and storage. The provider uses the full management plane to run the infrastructure (patching hosts, rebalancing workloads); customers reach a scoped subset through the console and APIs to create VMs, set network rules and assign permissions. Its reach makes it the most sensitive component in a cloud: losing control of a single host, switch or array is serious, but the management plane can reconfigure all of them at once, so a foothold there is a foothold everywhere.

Protecting management plane access

• Dedicated, hardened privileged access workstations. Malware on an everyday laptop can steal a live session token after sign-in, which bypasses MFA however strong; separating privileged sessions from email and browsing removes that root cause.
• MFA, ideally phishing-resistant, for every administrator.
• Network restrictions: console and API access only from a dedicated admin network or jump hosts, so stolen credentials cannot be replayed from anywhere.
• Named accounts with least-privilege roles: every action attributable to a person; a shared all-powerful account is vaulted for emergency (break-glass) use with alerting. Attribution needs one account per person and least privilege needs roles sized to the job; the two requirements are met separately.
• Logging of every management call, sent to a SIEM with alerts on destructive actions. This is detective and complements, not replaces, the preventive controls.

Maintenance mode

Host maintenance is orchestrated through the management plane. A host put into maintenance mode has its workloads live-migrated to other hosts and stops accepting new placements; it stays in the inventory so monitoring, logging and configuration management continue while it is patched and rebooted.

Blocking placements is only the first half of maintenance mode: a host that still runs workloads takes them down when it reboots. Preserving a VM's state does not keep it running either: a snapshot or a paused VM survives the reboot, but the workload is unavailable until the host returns. Only migrating it to another host keeps it serving. Workloads that cannot migrate, such as VMs pinned to the host by a mandatory affinity rule or bound to its local hardware, stop maintenance mode from completing; they must be moved by relaxing the rule, or shut down in a planned window.

Hot patching (live patching) applies certain hypervisor fixes in memory without a reboot, which avoids evacuation for those fixes. It does not cover updates that need a restart, such as BIOS/UEFI and other host firmware updates, or many hypervisor upgrades, so evacuation remains the routine path.

Evacuation needs spare capacity. A cluster patched without downtime must be able to absorb one host's workloads on the rest (N+1). With n equal hosts, that means keeping utilization at or below (n − 1) / n of total capacity: for a ten-host cluster about 90%, for a six-host cluster about 83%, less a margin for hypervisor overhead and reservations. Capacity planning, not tuning at maintenance time, is what keeps maintenance mode reliable: priority settings and reservations change how a shortage is shared out, not whether one host's load fits on the others.