CCSP Operating Cloud Infrastructure: Access, Hardening, Patching and Availability

Administrators should reach cloud systems through as few, as hardened and as well-identified paths as possible: one monitored entry point, protocols configured to resist attack, one identity source, and access that exists only while it is needed. Administrative access is the most valuable path into any environment, so CCSP sub-domain 5.2 treats it as the first thing to operate well.

One controlled entry point: the bastion host or jumpbox

A bastion host (the terms jumpbox and jump server are commonly used interchangeably) is a hardened system in a restricted subnet that administrators connect to first, and from which they reach the private systems. The private VMs accept SSH or RDP only from the bastion's address, so their management ports are never reachable from the internet. The value is consolidation: one system to patch first, one place to enforce MFA, and one choke point where every session is logged or recorded.

Removing standing access: just-in-time

Even a well-run bastion can leave standing privilege: anyone holding the admin role can use it at any hour. Just-in-time (JIT) access removes that. The path or role is granted only after a request is approved, for a named purpose and a fixed window, and is revoked automatically when the window closes. Between uses no one holds the privilege, so a forgotten role assignment or a stolen credential has nothing standing to unlock. A documented, monitored break-glass procedure covers emergencies.

Hardening the protocols themselves

• SSH: use key-based authentication and disable password authentication. Authentication then depends on possessing a private key rather than knowing a secret, so there is nothing for an attacker to guess. Also disable direct root login and protect private keys (passphrases, agent forwarding only where needed).
• RDP: require Network Level Authentication (NLA). With NLA the client must authenticate before the server builds a remote session, so an unauthenticated client never reaches the session and logon code on the server. Without it the server creates a session for any client that connects, which widens the pre-authentication attack surface.
• Secure terminal access and session controls: encrypted channels only (no Telnet or other cleartext protocols), plus idle and disconnected-session timeouts so abandoned sessions close.

Console-based access and SSO

Provider web consoles, hypervisor management consoles and monitoring tools are administrative access too. Single sign-on (SSO) federation makes the corporate identity provider the one source of identity for all of them: MFA and password policy are enforced once, group membership drives each tool's role, and a joiner, mover or leaver change made in the identity provider applies at the next sign-in to every federated console (sessions and tokens already issued last until they expire unless they are revoked, which is what SCIM deprovisioning automates). Local accounts in each tool are what make offboarding depend on memory, which is why federation is the structural fix.

Virtual clients for unmanaged devices

A virtual client (a hosted virtual desktop or published application reached through a broker) runs the admin tools inside the cloud. Only screen updates and keyboard and mouse input cross to the endpoint, so the endpoint acts purely as a display: data stays server-side and the device itself never joins the management network, provided clipboard, file and drive redirection are disabled. That property is what makes virtual clients the standard pattern for administration from personal or third-party devices the organization does not control.

A secure network configuration isolates tenants and tiers at layer 2 and 3, protects the core network services (DHCP and DNS) from spoofing, and encrypts traffic in transit with current protocol versions and the right kind of VPN.

VLANs and overlay networks

A VLAN separates broadcast domains on shared switches. The IEEE 802.1Q VLAN ID is 12 bits, so only 4,094 VLANs are usable (IDs 0 and 4095 are reserved). That ceiling matters wherever each tenant or environment needs its own layer-2 segment at scale. Overlay networks such as VXLAN encapsulate layer-2 frames inside UDP and carry them across the routed underlay, tagged with a 24-bit network identifier (VNI), which allows about 16 million segments. Overlays are how large multi-tenant clouds keep one isolated segment per tenant without the VLAN limit. A VLAN separates traffic but does not filter it: once VLANs are routed to each other, a firewall or access rule at the routing point decides what may cross.

DHCP and DNS integrity

• DHCP snooping on the physical or virtual switch marks the port of the legitimate DHCP server as trusted and drops DHCP server messages (offers and acknowledgements) that arrive on any untrusted port. A rogue DHCP server could otherwise hand clients a malicious default gateway or DNS server, setting up a man-in-the-middle position. Snooping also builds a binding table of address-to-port leases that features such as dynamic ARP inspection reuse.
• DNSSEC signs DNS records and builds a chain of trust from the root zone, so a validating resolver can confirm origin authentication and data integrity and reject forged answers, which defeats cache poisoning. It provides no confidentiality: queries and answers stay readable on the wire. Encrypted DNS transports (DNS over TLS or DNS over HTTPS) provide privacy; the two are complementary.

TLS configuration

TLS 1.0 and 1.1 are deprecated (RFC 8996). Endpoints should accept TLS 1.2 and 1.3 only, with modern authenticated-encryption (AEAD) cipher suites. The control that matters is the set of versions the server is willing to accept: as long as an old version remains enabled, a client that offers it, or an attacker interfering with the handshake, can end up using it. Removing 1.0 and 1.1 from the server's configuration is what retires them.

Forward secrecy means recorded traffic stays unreadable even if the server's long-term private key is stolen later. It comes from ephemeral (EC)DHE key exchange: each session's keys are derived from temporary values that are discarded afterwards, so the long-term key only authenticates the server and cannot recreate past session keys. In static RSA key exchange, by contrast, the session secret is encrypted to the server's long-term key, so possession of that key unlocks every recording. TLS 1.3 removed static RSA key exchange altogether; on TLS 1.2, restrict the configuration to ECDHE suites.

VPN choices

A dedicated private circuit to the provider gives a private, predictable path but no encryption of its own; organizations that need confidentiality on it run IPsec or MACsec over the circuit.

Cloud network security combines filtering (firewalls and network security groups), detection and prevention (IDS and IPS), deception (honeypots), assessment (vulnerability scans) and structure (bastion hosts and segmentation). Several of these come in near-twin pairs that differ in one property.

Stateful versus stateless filtering

The ephemeral-port rule follows from statelessness. When a client opens a connection, it uses a temporary high-numbered source port, and the reply comes back to that port. Consider a VM behind a stateless list that calls an external API: the outbound request to port 443 is allowed, but the response arrives inbound addressed to the VM's ephemeral port, so the list needs an inbound rule for the ephemeral port range as well. A stateful group would have matched the reply to the open connection.

IDS versus IPS

An intrusion detection system receives a copy of traffic (from a mirror or tap), out of band, so it can only alert. An intrusion prevention system sits inline in the traffic path and can drop malicious packets before they arrive. The difference is placement, not detection quality: the same signatures produce an alert on a copy and a block when the sensor is in the path. Inline placement also makes the IPS part of the availability path, so it is sized and made redundant like any other network hop.

Honeypots

A honeypot is a decoy system with no legitimate users and no real data, so any connection to it is suspicious, and it lets defenders study attacker technique. Design rules: load fabricated data only; place it in an isolated, monitored segment with no route to production; leave inbound traffic largely unfiltered so the activity it exists to observe can reach it; and apply outbound data control (rate limits or blocking on traffic leaving it) so a compromised honeypot cannot be used to attack anyone else. A network of honeypots is a honeynet. A honeypot invites attackers; a bastion host is built to admit only administrators.

Vulnerability assessments in the cloud

• Authorization comes first. The provider's terms and testing policy decide what a customer may scan. Public IaaS providers generally let customers scan their own VMs within published rules; SaaS providers often prohibit scanning their platform or require prior approval. Planning a cloud assessment therefore starts with reading that policy for each service in scope.
• Authenticated (credentialed) scans log in with a dedicated, least-privilege account and read installed package versions and configuration, so they report missing patches and insecure settings accurately. Unauthenticated scans see the system as an outsider does (open ports and service banners) and infer versions from them, which misses most locally installed packages. Each has a place: the outside view shows exposure, the credentialed view shows the patch and configuration state.

Segmentation and microsegmentation

Segmentation divides tiers (web, application, database) so each accepts traffic only from the tier in front of it. A perimeter firewall inspects north-south traffic (in and out of the environment); east-west traffic between VMs on the same host may never leave that host's virtual switch. Microsegmentation with a distributed firewall enforces rules at each VM's virtual NIC, so policy follows the workload and applies even between VMs sharing a host. Policies are usually written against workload labels or groups rather than IP addresses, so they survive migration and scaling.

Operating systems are hardened by applying an approved baseline, then kept hardened by monitoring running systems against it and remediating drift. That three-part cycle applies to Windows, Linux and hypervisor hosts such as VMware ESXi alike.

• Baseline: a documented secure configuration, typically from a CIS Benchmark, the vendor's security or hardening guide, or a government baseline. Remove unneeded services and packages, disable direct root or administrator remote login, enforce logging, and restrict local accounts. Bake it into a golden image so every new system starts compliant.
• Monitoring: an image fixes the configuration only at the moment of launch; administrators, installers and updates change it afterwards. Configuration compliance checks (for example a scanner evaluating each system against the CIS profile, or a configuration-management agent reporting state) compare the live settings of every running system with the baseline and report each deviation, such as an audit policy switched off or a service added outside change control.
• Remediation: correct drift automatically (configuration management re-applying the desired state) or through change management, and record approved exceptions. For autoscaled or stateless fleets, immutable infrastructure is stronger still: bake patches and baseline into a new image and replace the instances rather than changing them. Every instance then has the same provenance, the image's build record, which is simple to prove to an auditor.

Hypervisor hosts

Hypervisor hosts are hardened like any OS, and their configuration sits below anything guest hardening can see. Define the baseline once from the vendor's security configuration guide or the CIS Benchmark, apply it centrally from the management server as desired-state configuration (in VMware vSphere, host profiles or the newer cluster-level vSphere Configuration Profiles; other platforms have equivalent templates), run compliance checks to find and fix deviations, and minimize direct host access such as the local shell or SSH, because ad hoc changes made there are where host drift starts. Lockdown modes on hypervisors enforce that management goes through the management server only.

Patch management is the process of identifying, testing, deploying and verifying updates, and in the cloud it starts with knowing which layers you are responsible for patching.

Who patches what

For example, a flaw in a language runtime is the provider's to patch on a managed PaaS application service, but the customer's on an IaaS VM where the customer installed that runtime; a library bundled inside the customer's own application package is the customer's in both. In a private cloud, the operator also owns hypervisor and firmware patching.

The normal process

1. Inventory systems and monitor vendor advisories.
2. Assess severity and exposure (is it being exploited? is the system internet-facing?).
3. Test in a staging environment that mirrors production.
4. Deploy in stages (pilot, then waves) with a rollback plan, through change management.
5. Verify with an authenticated scan or compliance check, and record the result.

Each step guards against a different failure: testing catches a faulty patch before it reaches the fleet, staged waves limit the blast radius of anything testing missed, and the rollback plan restores service quickly. Critical fixes follow the same steps on a compressed timeline set by policy, rather than waiting for the routine cycle.

When a patch cannot be deployed yet

If a vulnerability is actively exploited but the patch cannot go in immediately (testing pending, a change freeze, or no vendor patch yet), apply the vendor's interim mitigation or another compensating control (restrict who can reach the system, disable the vulnerable feature, add a virtual-patch rule on a WAF or IPS) and monitor closely until the tested patch is deployed. Compensating controls reduce the exposure now while keeping the change process intact; they are documented with an owner and an end date, and removed once the patch lands.

Clustered hosts are kept available by pooling hosts and storage so that VMs can move or restart elsewhere: maintenance mode and live migration handle planned work, high availability (HA) handles unplanned host failure, admission control guarantees there is room to restart, distributed resource scheduling and dynamic optimization keep load balanced as demand changes, and storage clusters keep the data underneath available.

Dynamic optimization

Dynamic optimization is the continuous, automated adjustment of resources to changing demand. Instead of placing workloads once and leaving them, the platform keeps measuring utilization and acts on it: migrating VMs off busy hosts, rebalancing after a host joins or leaves, resizing or adding instances, and consolidating light loads so idle hosts can be powered down to save energy. Distributed resource scheduling is the hypervisor-cluster form of it; autoscaling is the cloud-service form. Every such action stays inside the placement rules and capacity reservations the operators have set.

Storage clusters

A storage cluster is two or more storage nodes working together as one system for capacity, performance and resilience, so that the loss of a disk, controller or node does not make data unavailable. The CCSP body of knowledge describes two architectures:

• Tightly coupled: the nodes share a common backplane and physical disks and operate as one unit, usually from a single vendor. Performance is high and consistent, but growth is limited to what that architecture supports.
• Loosely coupled: each node is independent with its own storage, joined over a network, and data is distributed across nodes. Capacity scales out by adding nodes, while the performance available from any one node is limited by that node.

Putting the features together

Before planned host work, such as replacing a memory module, maintenance mode moves the running VMs away first, so the work causes no outage; HA is the safety net for failures nobody planned. Admission control turns an "N+1" design into an enforced reservation: a new VM is refused power-on if starting it would leave too little spare capacity to restart a failed host's VMs. For a redundant pair, such as two domain controllers or two load-balanced front ends, an anti-affinity rule keeps the members on different hosts so automated balancing never concentrates both on one failure point. Affinity is the opposite rule, used to keep tightly coupled VMs on the same host.

Guest OS availability needs protection inside or above the VM, because host-level HA monitors the hosts: it acts when a host stops responding, and has nothing to act on when the problem is inside a guest whose host is fine.

• VM (guest) monitoring watches heartbeats from the virtualization tools inside the guest, optionally together with disk and network I/O activity, and resets the VM when they stop. It turns a silent guest hang into an automatic restart, though the restart still takes minutes.
• Fault tolerance keeps a secondary copy of the VM running on another host, kept continuously synchronized with the primary (classically by lockstep execution, in current implementations by rapid checkpointing), so a host failure causes no restart at all. Because the secondary mirrors the same guest, it shares any guest OS fault, and a guest patch reboot affects both copies. It also doubles the resources consumed.
• Guest-level or application clustering runs two or more separate guest OS instances (for example a database or OS failover cluster), placed on separate hosts with anti-affinity. A different OS instance takes over in seconds after a host failure, a guest crash, or while one node is being patched.

Choosing among them starts from the recovery objective and the failure that must be survived: minutes of restart are acceptable for many services, while those that must survive guest faults and patching without interruption need more than one guest.

Performance, capacity and hardware are monitored by measuring each layer (network, compute, storage, response time and the physical components) against a known normal, trending the results to predict exhaustion, and getting alerts from a source that survives the failure being watched.

Baselines before thresholds

Workloads differ in what normal looks like: a reporting server may peak every night, a web tier follows business hours, and a file server is quiet for weeks. The same reading can be routine on one and an incident on another. The first step is therefore a baseline of normal behaviour per workload and per metric, captured over enough time to include its cycles; alerts then fire on deviation from that baseline, which catches both sudden spikes and slow changes such as steadily climbing memory use.

Reading the four areas

• Compute: CPU utilization, memory, and on hypervisors CPU ready time (VMs waiting for a physical CPU).
• Storage: read/write latency, IOPS, throughput and queue depth per datastore. Storage contention shows up inside the guest as I/O wait: the workload is waiting on disk rather than being limited by CPU.
• Network: throughput, packet loss, retransmissions and latency.
• Response time: synthetic tests and real-user timing show the symptom users feel; they confirm a slowdown, and the layer metrics above locate it.

Capacity trending

Capacity monitoring must warn early enough to act. The useful question is not how full a resource is today but when it will be full, compared with how long it takes to add more. Alerting on the projected time until full, calculated from recent growth, against the procurement or provisioning lead time gives warning that adapts automatically when growth speeds up or slows down. (The ITIL capacity management practice itself belongs to sub-domain 5.3.)

Hardware monitoring

• What is watched: disk health, CPU, fan speed, temperature, power supplies and memory errors.
• Disks: SMART (Self-Monitoring, Analysis and Reporting Technology) attributes such as reallocated and pending sector counts rise as a physical drive degrades, giving per-drive warning before it fails, so the drive can be replaced while redundancy is still intact.
• Out-of-band monitoring: each server's baseboard management controller (BMC) has its own processor, power and network port and reads the sensors independently of the host OS. It is polled over IPMI or Redfish on the isolated management network, so hardware alerts keep arriving when the hypervisor has crashed or the host is powered off. The BMC itself is a privileged interface and belongs on a restricted management network.
• Public cloud: under shared responsibility the provider monitors the physical hardware. Generally, and on the major IaaS platforms, customers are not given host sensors or BMCs, even on dedicated hosts (a few bare-metal offerings do expose IPMI to the customer). Customers consume the provider's host health and scheduled-maintenance events and watch guest-level symptoms (disk latency, I/O errors) to move or replace a VM.

Host and guest backup must produce copies that are independent of production storage, protected from change, cover the host's own configuration as well as the guests, and are proven by tested restores.

• Snapshots are not backups. A snapshot depends on its base disk and usually lives on the same datastore, so it fails or is encrypted along with it. Use snapshots for short-term rollback (before a patch), not retention.
• Replication is not backup. Synchronous or asynchronous replication faithfully copies corruption, deletion and ransomware-encrypted writes to the target, whether it is in the same site or another region. It protects availability against site loss, not data against bad writes.
• RAID is not backup. It survives disk failure, not valid writes that destroy data.
• Separate, immutable copies: backups on separate storage (off the primary array, ideally another location) that cannot be modified or deleted during the retention period give a clean restore point after ransomware. (Immutability and retention design in depth are covered with storage in Domain 3.)
• Host configuration backup: VM backups capture the guests, but each hypervisor host's own settings (virtual switches and network configuration, storage paths, security and service settings) live on the host. Export that configuration on a schedule, keep it off the host, and test restoring it, so rebuilding a failed host is a reinstall plus a configuration restore.
• Guest OS backup: image-level backups of VMs (with application-consistent options for databases, which quiesce the application before the copy) plus file-level restore, scheduled so the jobs do not all load shared storage at once.
• Restore testing: a backup that has never been restored is an assumption. Test both guest and host restores regularly against the recovery time and recovery point objectives.

The management plane (the virtualization manager, orchestration engine and provider control APIs) is operated by scheduling work so it does not contend for shared resources, keeping orchestration from fighting planned maintenance, and protecting the management plane itself when it is maintained. It holds the cloud's inventory, schedules, workflows and permissions, so it is both the most powerful tool and the most important system to safeguard.

Scheduling

Recurring jobs (backups, malware scans, patch installs, reports) all draw on the same shared storage and network. Left at default start times they tend to bunch together, and the resulting contention slows production and the jobs themselves. Good scheduling staggers start times in batches across the window and respects dependencies (patch, then reboot, then verify), which spreads the load using the infrastructure already in place. Prioritisation controls such as storage I/O shares or per-VM IOPS limits do not solve this: they decide who wins under contention but leave the total demand at the peak unchanged, so the throttled jobs simply get less I/O and overrun further. Spreading demand across time removes the contention instead of rationing it.

Orchestration during maintenance

Orchestration acts on what it observes. During planned maintenance, health checks fail by design, so self-healing automation may rebuild or restart resources repeatedly and overload what remains. The maintenance procedure should pause or suspend automated remediation for the affected resources (or put them into a maintenance state the automation recognises) for the duration of the window, and resume it afterwards, so detection everywhere else is unaffected.

Maintaining the management plane itself

• Before upgrading or patching the management server, take a configuration backup of the management plane (inventory, schedules, orchestration settings, roles and permissions) and rehearse the restore, with a rollback plan approved through change management.
• Host HA runs on the hosts themselves and keeps restarting VMs after host failures while the management server is offline, so running workloads stay protected throughout a management-server upgrade.
• Restrict management-plane access to SSO identities with MFA and least privilege, through the controlled access paths described above, and log every action.