CCSP: Planning and Implementing Cloud Infrastructure Security Controls

Physical and environmental protection is implemented by whoever controls the space the hardware sits in, and everyone else gains assurance about it rather than building it. That one rule resolves most scenarios, because the same kind of server can sit in very different places:

Two principles follow. First, an assurance report is bounded by its scope: it describes the facilities and controls listed in it and nothing else, so it cannot be stretched over a location the provider does not operate. Second, when a location cannot be made physically secure, move the protection onto the data. For example, a gateway on a factory floor that anyone on shift can reach should store data only on disks encrypted with keys bound to that device's trusted platform module (TPM) and measured boot, so the disk is unreadable if it is removed or the device boots outside its trusted state. Physical barriers still help, but they delay and deter; device-bound encryption decides what a thief actually obtains.

The design of a data center itself (site selection, tiers, redundant power and cooling) belongs to the secure data center design topic; this topic is about the controls that protect people, equipment and media once the site exists.

Physical access control works in layers, and each control verifies something different: the perimeter keeps people off the site, entry controls decide who comes in, internal controls limit where they go, and surveillance records what happened. A typical sequence runs from fencing, lighting and vehicle barriers, through staffed reception with escorts, to badge-controlled doors and stronger checks at server halls and cages. To pick a control, ask what it actually verifies and whether it prevents or only records:

The common mistake is to answer a prevention requirement with a detective control, or to answer one weakness with a control that addresses a different one: a control that counts people does not check who they are, and a control that checks who they are does not count them.

Fail-safe, fail-secure and free egress

Electric locks must decide what happens on power loss or a fire alarm. A fail-safe lock releases (people can leave, but anyone can enter); a fail-secure lock stays locked (the space is protected, but people could be trapped). Life safety always comes first, so the goal is to separate the two directions: the outside stays secured while the inside always opens. That is done with free egress hardware, a panic bar or lever on the inside that opens the door mechanically whatever the state of the lock, so entry still needs authorization but exit needs no key, card, code or special knowledge. Building and fire codes such as NFPA 101 generally require this; the exceptions they permit, such as delayed-egress or access-controlled egress locks, are tightly specified and must release on a fire alarm or power loss.

Environmental protection detects fire, heat, humidity and water early and suppresses fire with the least harm to people and equipment. Detection comes first because electrical fires usually smoulder: they release fine smoke particles long before flames or a significant temperature rise.

Alongside fire detection, temperature and humidity monitoring catches cooling failures and conditions that cause static discharge (too dry) or condensation (too humid), and water-leak sensors under raised floors and near cooling units catch leaks before they reach equipment.

Suppression system types

Halon is no longer produced under the Montreal Protocol and is not a choice for new systems. Codes may still require sprinklers as a backup to a gas system, which is why pre-action sprinklers are so often paired with clean agents.

Boundary protection controls what can cross the edge of a network segment through managed interfaces, and management-plane separation keeps the interfaces that control the infrastructure out of reach of the workloads running on it. Both come from the NIST SP 800-53 system and communications protection family: SC-7 boundary protection and SC-2 separation of system (management) functions from user functions.

Three separate questions about outbound traffic

When workloads in private subnets talk to provider services or the internet, three different questions arise, and each has its own control:

Two refinements matter for the third question. Address-based rules work poorly when a destination's addresses change often or are shared by many customers; an egress firewall or forward proxy that filters on the requested domain name (from the proxy request or the TLS server name) keeps working as addresses change. And where a private endpoint leads into a multi-tenant service, a policy on your own resources protects your data but says nothing about other parties' resources reachable through the same endpoint. An endpoint policy is attached to the path itself, so it can restrict every request through it to resources your organization owns, which closes the path as an exfiltration route.

Separating the management plane

Management interfaces are the highest-value targets in a private cloud: hypervisor and virtualization-manager consoles, storage and switch management, and baseboard management controllers (BMCs, reached over IPMI or Redfish), which power-cycle servers, mount media and open consoles below the operating system. The principle is to remove reachability first, then harden what remains: put them on a dedicated, out-of-band management network reachable only from jump hosts or privileged access workstations, so a compromised workload has no route to them at all. Hardening an interface that stays reachable from tenant traffic reduces the likelihood of compromise but leaves the exposure in place.

A public cloud's console and APIs are internet-facing by design, so the customer cannot place them behind its own network boundary; network controls govern only the traffic that passes through them. The enforceable point is the sign-in. With federated identity, the identity provider's conditional-access policy can require conditions such as a managed, compliant device before it issues an administrative session, and that requirement applies wherever the administrator connects from. Multi-factor authentication proves the person; a device condition proves the workstation; they answer different requirements.

Communications are protected in transit by encryption that covers the whole span that must be protected; a private path is not an encrypted path, and every encryption layer protects only the stretch between the two points that encrypt and decrypt it.

A reliable method is to draw the path and mark every point where traffic is decrypted. Suppose a partner's file transfer arrives over a site-to-site VPN that ends on a cloud VPN gateway, and is then forwarded to a storage service. The VPN protects the internet stretch; from the gateway onwards the transfer is protected only if another layer (for example TLS to the storage service) covers it. The same reasoning gives three rules:

• Private is not encrypted. Dedicated circuits run through carrier and provider equipment. They reduce exposure to the internet, but confidentiality on the circuit needs encryption added over it (MACsec on the link or IPsec across it).
• Link and tunnel encryption end at devices, not at applications. When protection must reach all the way to the processing systems, choose encryption that those systems terminate, typically TLS on the workloads, alone or on top of link or tunnel encryption.
• Evidence comes from controls you operate. A provider's statements about encrypting its own backbone are part of its responsibility and appear in its attestations, but they describe the provider's network, not the customer's traffic between its own components. When a company must demonstrate encryption between its own systems, it configures that encryption, manages the certificates and keeps the configuration as evidence.

Storage infrastructure is protected in layers: the network decides which hosts may reach storage, the storage system decides which hosts are presented each volume or share, the protocol decides which users they are and whether messages are protected, and encryption at rest protects the media. Encryption at rest defends against lost, stolen or improperly disposed media; it is transparent to any host or user the storage system already serves, so it cannot replace access control.

Block storage: zoning and LUN masking

On a shared array, zoning in the storage fabric decides which host ports can communicate with which array ports, and LUN masking on the array decides which host initiators are presented each logical unit (LUN). Used together, they make a volume visible only to the hosts that should mount it. Isolating storage traffic on its own network is still good practice, but it separates storage from other traffic types rather than separating hosts from each other.

File storage: authentication and message protection in the protocol

The pattern to remember: network filtering decides which hosts may connect, presentation decides which hosts see which storage, protocol authentication decides which users they are, integrity mechanisms prove messages are untouched, and only encryption keeps content secret on the wire.

Denial-of-service protection means matching the defence to the resource the attack exhausts: network capacity, application request handling, or, on auto-scaling and pay-per-use services, the customer's budget. A defence placed behind the exhausted resource cannot help, because the damage happens before traffic reaches it.

Elastic platforms change what availability means. When the platform scales automatically, an attacker can succeed by spending the customer's money rather than by taking the service down, so cost belongs in the impact analysis. Detection, such as budget and anomaly alerts, is still needed to notice an attack; prevention comes from per-caller limits on consumption.

Identification is the claim of an identity, authentication is the proof of that claim, authorization is the decision about what the proven identity may do, and accountability is the record that ties each action to that identity. When a scenario describes a failure, decide which of the four broke, because each has different fixes.

• A username, email address or service principal name is identification. A password, a hardware key or a one-time code are authentication factors (combining different categories, such as something you know and something you have, makes it multi-factor). The permission check that follows is authorization, and the audit trail provides accountability.
• Accountability needs identification to be individual. If three contractors run database maintenance through one shared "dbadmin" account, every log entry is accurate and still cannot name a person, because the identity itself was never individual. Evidence that was never recorded cannot be produced later by any other control. The fix is at identification: one named identity per person, which gains administrative rights by assuming a role or through privileged access management when needed.
• Network location is not identity. An internal API that accepts any request from an address inside the corporate range has replaced authentication with location, so any foothold on the network inherits its trust. Zero-trust design authenticates every caller, including workloads, with strong workload identities (for example mutual TLS with short-lived certificates or signed service tokens) and evaluates authorization on every request.

Protecting the most powerful identities

Many cloud accounts have a root or owner identity that the account's own permission policies cannot restrict, and every provider has top-level tenant or organization administrator roles with similar reach. Because authorization does not contain these identities, strong authentication and minimal use are their safeguards:

• Register a phishing-resistant MFA factor, such as a FIDO2 hardware security key, as soon as the account or tenant exists.
• Create no long-lived access keys for it.
• Reserve it for the few tasks only it can perform (some account-level settings, recovery), and do daily work as named, least-privilege administrators.

With an organization service, preventive guardrail policies set centrally can restrict member accounts, including their root identities. On some platforms (in AWS Organizations, for example) they do not apply to the management account itself, whose administrators can edit or detach the guardrails for everyone. Its top-level identity is therefore the most powerful credential in the organization: protect it first, restrict who can use it, and run no workloads in the management account.

Cloud authorization is designed by choosing a model that scales with least privilege, delegating to third parties with temporary, customer-bound credentials, and separating duties so that no single person can both control and use a sensitive function.

In ABAC the attributes are the permissions. Anyone who can write a security-relevant tag, or edit their own attribute in the directory, can grant themselves access. Treat changing those attributes as a privileged action in its own right: restrict who may set or change them, require them at resource creation, and grant that right separately from the right to use the resources.

Delegating to a third party's service

A vendor that needs access to a customer's account should assume a role the customer creates. The role trusts the vendor's account, each assumption issues short-lived credentials, and the customer can revoke access at any moment by changing the trust policy. Long-lived access keys handed to a vendor are a standing secret the customer cannot see or control once it leaves.

The vendor's service is a deputy: it acts in many customers' accounts with authority each of them granted. If another customer of the same vendor learns your role's identifier, it can ask the vendor's service to use it, and the service, which does hold permission, complies. That is the confused deputy problem. The mitigation is a customer-unique external ID, generated by the vendor for each customer and required as a condition in the role's trust policy, so the vendor can only assume your role while acting for you. Neighbouring terms differ in what the attacker does:

Separation of duties on infrastructure functions

• Key administrators versus key users: those who manage key policies, rotation and deletion should not also encrypt and decrypt data with the keys, and workload roles that use keys should not manage them.
• Dual control where a role can change its own rights: if any single administrator can edit a policy to grant themselves access, the separation depends on their restraint. Requiring a second administrator's approval removes that single point of trust, while monitoring only reports misuse after the fact.
• Authoring versus approving changes: in infrastructure as code, the person who writes a production change must not also approve and merge it; the repository should enforce an independent reviewer.
• Log administrators versus workload administrators: the people whose actions are logged should not control the logging (see the audit section).

Hardware security modules strengthen key protection, but in a different dimension. FIPS 140-3 validation assures the cryptographic module itself, from Level 1 (approved algorithms) through Level 2 (tamper evidence and role-based operator authentication) and Level 3 (physical tamper resistance and identity-based operator authentication) to Level 4 (protection against environmental attacks). It says nothing about which people are allowed to change a key's policy; that remains a separation-of-duties decision in the key management service.

Audit mechanisms are the log sources, packet capture and correlation that let investigators reconstruct what happened, and each source records a different kind of event. Start from the question, then pick the source that records that kind of event and is owned by a party who can provide it:

Packet capture in the cloud

IaaS customers have no physical access, so physical taps and switch SPAN ports are replaced by virtual traffic mirroring: the provider copies packets from selected virtual network interfaces to a sensor or analyzer (often through a load balancer in front of a sensor pool) without software on the VMs. Two limits decide where it helps:

• Capture where the traffic is readable. Content is visible only between the point that decrypts traffic and the point that re-encrypts it, so choose an interface on the clear-text side of whichever component terminates TLS.
• TLS 1.3 provides forward secrecy through ephemeral (EC)DHE key exchange in its standard handshakes (PSK-only resumption is the exception), so recorded sessions cannot be decrypted later, even with a server's private key. Captures still provide timing, volumes, destinations and, unless Encrypted Client Hello is used, handshake details such as the server name. Content has to come from an endpoint before encryption or after decryption, such as process memory or application logs.

Full capture is high-volume and can record personal data, so it is targeted and time-bound rather than always on.

Collection coverage and tamper resistance

Logs protect only what they cover and only if the people they record cannot alter them. Configure control-plane logging centrally, at the organization level for every account and every Region, delivered to a separate security or log-archive account that workload administrators cannot change, and alert on changes to logging configuration. Settings managed account by account tend to diverge, and local administrators can change them. Preventive guardrails such as policies that deny the use of unapproved Regions are a valuable additional layer, because they reduce where an attacker can act, but they do not produce a record of what happened; a recording requirement is met only by logging.

Proving that logs have not been altered is an integrity requirement and needs integrity controls: write-once (WORM, compliance-mode) retention that no administrator can shorten or remove, combined with integrity digests (signed hash chains) that anyone can validate later. Confidentiality and availability controls on the log store serve other purposes. (How data-event logs are scoped, retained and handled as evidence is covered in the data-event auditability lesson.)

Correlation

Attack chains are often built from events that look normal one at a time. For example, a successful sign-in after a burst of failed ones, then a new mail-forwarding rule, then a large download from a file-sharing service. A SIEM correlation rule joins events from different sources on shared attributes (identity, resource, address) within a time window and alerts on the combination. Correlation depends on two foundations:

• Common time: synchronise every source to a common time service (NTP) and normalise timestamps to UTC at ingestion, so events from the identity provider, the cloud and on-premises systems line up in their true order.
• A shared identity key: with federation, the cloud log may record only a role and a generic session name while the identity provider records the employee. Configure the federation to pass a user-unique value (such as a source identity or the role session name) into every role session, so each control-plane event carries the person's identity and federation stays in place.