Courseiva
CCSPChapter 7 of 16Objective 3.1

Cloud Platform and Infrastructure Security

How do you keep your company's cloud data safe when you don't even control the building it's stored in? This is the core problem that Cloud Platform and Infrastructure Security solves for anyone responsible for protecting cloud assets. For a CCSP candidate, understanding how physical security at the data centre and network security in the cloud combine is essential, because the exam will test how these controls protect against real-world threats.

12 min read
Intermediate
Updated Jul 23, 2026
Editorial oversight: Johnson Ajibi· Security Systems Architect · MSc IT Security · IEEE Senior Member

A simple way to picture Cloud Platform and Infrastructure Security

The Apartment Building Security Analogy

A secure apartment building is a layered system of controls. The building itself has a physical address, just like a cloud data centre has a physical location. The front door has a locked entry with a key fob or intercom system, which is the equivalent of a network firewall, controlling who can enter from the outside. Inside the lobby, a security guard monitors the entrance and checks visitors, similar to an intrusion detection system watching for suspicious activity. The hallways on each floor are like virtual local area networks (VLANs), separating different groups of tenants or departments from each other. Each individual apartment door has its own deadbolt lock, representing a virtual private cloud (VPC) or subnet, providing a private space for each tenant's data and applications. The elevator might require a specific key card to reach certain floors, which is like an access control list (ACL) or IAM policy that grants permissions based on identity. The building might also have a generator for backup power (an uninterruptible power supply in a data centre) and a sprinkler system for fire suppression. Finally, the building management keeps logs of who enters and leaves, just as cloud providers log all API calls and access events for auditing. If a thief tries to bypass the front door by climbing through a window, the building's exterior is also alarmed—a parallel to perimeter security controls like demilitarized zones (DMZs). This layered, physical and digital security ensures that even if one layer fails, others still protect the valuable assets inside.

How It Actually Works

Cloud Platform and Infrastructure Security is the combination of physical and network controls that protect the underlying hardware, software, and networking components of a cloud environment. Think of it this way: when you rent an apartment, you have a key to your unit (your virtual machine or application), but the landlord controls the building's front door, the elevator, and the security cameras. In cloud computing, the cloud provider (like Amazon Web Services, Microsoft Azure, or Google Cloud Platform) is the landlord. They are responsible for the physical security of the data centre, the security of the network cables, and the servers running in their facilities. But as a customer, you are still responsible for the security of your own 'apartment'—your virtual networks, your operating systems, your applications, and your data.

Let's break down the two major halves: physical security and network security.

Physical security is about protecting the actual buildings where the cloud servers live. Cloud data centres are massive warehouses filled with racks of servers, storage systems, and networking gear. To protect these facilities, providers use multiple layers of control:

Perimeter security: Fences, walls, and vehicle barriers prevent unauthorised vehicles and people from getting close to the building. Security guards patrol the area.

Building access: You need a special badge or biometric scan (like a fingerprint or iris scan) just to enter the building. These credentials are strictly managed and logged.

Internal zones: Inside the building, there are further restricted zones. Only specific engineers can enter the server room floor. Access is based on job role and time of day.

Surveillance: Video cameras (CCTV) record everything. These recordings are kept for a period and can be reviewed if an incident occurs.

Environmental controls: The data centre has fire suppression systems (often using gas, not water, to avoid damaging electronics), backup generators in case of power failure, and cooling systems to prevent servers from overheating.

Visitor management: All visitors are escorted at all times. They must sign in, state their purpose, and be logged.

Network security is about protecting the connections between computers and data. This is where the 'virtual' part happens. Even though the servers are in a physical building, communication between them happens over a network made of physical cables and wireless signals. The cloud provider builds this network, and you build your own private network on top of it. Key network security controls include:

Firewalls: A firewall is a system that monitors incoming and outgoing network traffic and decides whether to allow or block specific traffic based on a defined set of security rules. In the cloud, this is often a virtual firewall called a security group or network access control list (NACL).

Virtual Private Cloud (VPC): A VPC is your own logically isolated section of the cloud network. It is like having your own private, gated community inside the larger city of the cloud provider. You decide which IP addresses to use, which subnets to create, and how traffic flows between them.

Subnets and segmentation: You can divide your VPC into smaller networks called subnets. For example, you could put your web servers in a public subnet that can talk to the internet, and your database servers in a private subnet that can only talk to the web servers, not the internet directly. This is called network segmentation.

Demilitarized Zone (DMZ): This is a physical or logical subnet that separates your internal network from the untrusted outside network (the internet). Any server that needs to be directly accessible from the internet (like a website) is placed in the DMZ. If an attacker breaches a server in the DMZ, they still cannot directly access the internal servers.

Load balancers: A load balancer distributes incoming network traffic across multiple servers so that no single server gets overwhelmed. This helps with availability but can also act as a security device, hiding the IP addresses of the backend servers from the internet.

Intrusion Detection and Prevention Systems (IDS/IPS): These systems monitor network traffic for malicious activity. IDS just alerts you, while IPS can automatically block the malicious traffic.

Encryption in transit: Data moving across the network between your users, your cloud servers, and the third-party services should be encrypted. This is typically done using Transport Layer Security (TLS), which is the technology behind the little padlock in your browser's address bar.

Why do we need all of this? In a traditional on-premises data centre, you own and control everything from the building to the cables to the servers. In the cloud, you share part of that responsibility with the provider. This is called the Shared Responsibility Model. The cloud provider is responsible for security *of* the cloud (physical security, the network, the hypervisor), and you are responsible for security *in* the cloud (your operating system, your applications, your data, your user access). Understanding this model is the single most important concept for the CCSP exam.

To implement these controls, you use both the cloud provider's management console (a web interface) and APIs (programmatic instructions sent by software). You configure security groups, set up VPCs with specific subnets, create firewall rules, and enable logging. The exam will test your understanding of how these controls interact and where the 'line' is drawn between provider and customer responsibility.

This flowchart shows how internet traffic passes through multiple layers of network security (firewall, load balancer, DMZ, subnets, security groups) to reach the database, while physical security controls protect the data centre itself.

Walk-Through

1

Assess Shared Responsibility

Read your cloud provider's documentation to understand exactly where their responsibility ends and yours begins. For example, the provider secures the physical data centre, but you manage your virtual networks. This step prevents you from assuming the provider handles something they do not.

2

Design the VPC and Subnets

Create a Virtual Private Cloud (VPC) and divide it into subnets. Place public-facing servers (e.g., web servers) in a public subnet, and internal servers (e.g., databases) in private subnets. This segments the network, so an attacker cannot easily jump from a public server to a database.

3

Configure Firewall Rules (Security Groups/Network ACLs)

Define traffic rules. Use security groups to allow only necessary inbound traffic (e.g., port 443 for HTTPS). Use network ACLs as an additional stateless barrier for subnets. Remember: security groups are stateful, so you only need an inbound rule for replies; network ACLs need both inbound and outbound rules.

4

Enable Logging and Monitoring

Turn on VPC Flow Logs to capture metadata about all network traffic. Enable API logging (e.g., AWS CloudTrail, Azure Monitor) to track changes in configuration. Send logs to a central storage (like Amazon S3 or Azure Log Analytics) for analysis and retention.

5

Verify Physical Security via Compliance Reports

Request and review your cloud provider's SOC 2, ISO 27001, or similar audit reports. These documents prove that the provider's physical security controls (guards, cameras, access controls) have been independently tested. Do not rely on assumptions; verify through third-party audits.

6

Test the Configuration with a Penetration Test

Simulate an attack against your cloud architecture from the internet (within the bounds of the provider's policy and with permission). Try to bypass the firewall rules. Identify misconfigured security groups or exposed services. Fix any gaps before going live.

What This Looks Like on the Job

Imagine a medium-sized company called 'GreenEnergy Solutions' that provides solar panel monitoring software. They have decided to move their application to a cloud platform. The IT security lead, Maria, is tasked with designing the network and physical security architecture.

Step 1: Planning the architecture Maria first reads the cloud provider's Shared Responsibility Model document. She identifies that the provider will handle the physical security of the data centre (guards, cameras, power) and will secure the underlying network hardware (routers and switches). However, Maria is responsible for everything within her virtual network: the VPC, subnets, firewalls, and the security of the virtual servers themselves.

Step 2: Creating the VPC and subnets Maria goes to the cloud provider's console and creates a VPC. Inside it, she creates three subnets:

- A public subnet for the web servers that will serve the monitoring dashboard to customers. - A private subnet for the application servers that process data. - A second private subnet for the database servers that store customer data. She ensures that the public subnet cannot directly initiate connections to the private subnets, except through specific security rules.

Step 3: Configuring firewalls and security groups Maria creates a security group for the web servers. She configures it to allow inbound traffic only on port 443 (HTTPS, the secure web traffic port) and only from the entire internet (since customers need to access the dashboard). She creates a second security group for the database servers. This group allows inbound traffic only on port 3306 (MySQL database port) and only from the security group assigned to the application servers. This is called micro-segmentation—restricting traffic to the minimum necessary.

Step 4: Setting up network segmentation and DMZ Although not a classic DMZ, Maria's architecture achieves a similar effect. The web servers are in a public subnet (the DMZ element). If a hacker compromises a web server, they cannot directly reach the database because the database security group explicitly only allows traffic from the application servers. To move laterally, the attacker would need to first compromise an application server, which is not directly internet-facing.

Step 5: Enabling logging and monitoring Maria enables VPC Flow Logs, which record every network packet that goes into and out of the VPC. She also enables CloudTrail (or its equivalent) to log every API call made to the cloud provider, including when someone creates a new server or changes a firewall rule. These logs are sent to a central logging service for analysis.

Step 6: Physical security verification When the cloud provider offers an option to select a specific data centre region (e.g., 'Europe West'), Maria chooses it to comply with GDPR. She also asks the provider for their SOC 2 and ISO 27001 certification reports, which prove that the provider's physical security controls are independently audited. She does not need to visit the data centre, but she verifies the provider's security controls through these reports.

Step 7: Testing the architecture Before going live, Maria conducts a penetration test within the boundaries allowed by the provider's terms of service. She uses tools to simulate an attack from the internet, checking if the firewall rules and security groups work as expected. She finds a misconfiguration in a security group that exposes a test server to the internet and fixes it immediately.

What happens on exam day? A CCSP question might describe a scenario where the company's internal network is compromised. The correct answer will likely involve using network segmentation (subnets and security groups) to prevent lateral movement, rather than just relying on a firewall or encryption. The exam wants you to understand the practical order of operations and where responsibility lies.

How CCSP Actually Tests This

The CCSP exam, specifically under Domain 3 (Cloud Platform and Infrastructure Security), tests your ability to design and implement physical and network security. The exam is not about memorising specific AWS or Azure console paths—it is vendor-neutral. Instead, it tests your understanding of the *concepts* and *principles* that apply to any cloud provider.

What concepts does it love to test? - Physical security controls: Multi-layered perimeter defence, access control (mantraps, biometrics, CCTV), and environmental controls (HVAC, fire suppression, backup power). You must know which controls fit which scenario—for example, a mantrap (a small room with two interlocking doors) is used to prevent tailgating, not just any access control. - Network security controls: Firewalls, IDS/IPS, VPCs, subnets, DMZ, TLS, and VPNs (Virtual Private Networks). A VPN is an encrypted tunnel between your on-premises network and the cloud. - The Shared Responsibility Model: This is the most tested concept. The exam will ask you to classify specific responsibilities as either provider or customer. For example, patching the hypervisor (the software that manages virtual machines) is the provider's job; patching the guest operating system (the OS inside your VM) is your job. - Network segmentation and micro-segmentation: You need to know why segmentation boosts security (limits blast radius) and how to implement it (using subnets, security groups, and network ACLs). - Encryption in transit and at rest: You must know that TLS secures data moving across the network, while encryption at rest protects stored data. - Logging and monitoring: The exam expects you to know that logs (like VPC Flow Logs, DNS logs, API logs) are essential for incident response and auditing.

What traps do they set? - Trap 1: Confusing provider vs customer responsibility. A question might say 'You have a server that is infected with malware. What should you do?' Many beginners would say 'Ask the provider to fix it.' That is wrong—the provider patches the infrastructure, not your running OS. The correct answer is to reimage the server from a known good backup. - Trap 2: Thinking encryption solves everything. A question might say 'All data is encrypted, so we do not need firewalls.' That is a trap. Encryption protects data if it is intercepted, but it does not prevent an attacker from accessing a vulnerable API endpoint. Defence in depth requires multiple layers. - Trap 3: 'The cloud is just someone else's computer' and therefore security is all the provider's problem. This is the wrong mindset. The Shared Responsibility Model makes the customer accountable for their own data and configurations. - Trap 4: Confusing security groups with network ACLs. A security group is stateful (if you allow inbound traffic, the outbound reply is automatically allowed, regardless of outbound rules). A network ACL is stateless (you must explicitly define both inbound and outbound rules). The exam loves this distinction.

What question types appear? - Multiple-choice questions asking you to identify the correct control for a given threat. - Scenario-based questions where you must select the sequence of steps to secure a new cloud deployment. - 'Which of the following is a physical security control?' answer selections will include a mix of physical and logical controls (e.g., a firewall is not physical, a badge reader is). - 'True or false' style questions rephrased as statements. For example: 'In the Shared Responsibility Model, the cloud provider is responsible for encrypting your data.' Answer: False.

Key definitions to memorise for the exam: - Hypervisor: Software that creates and runs virtual machines. It sits between the hardware and the guest OS. The cloud provider secures it. - Tenant: A single customer of a cloud provider. Tenants share the physical hardware but are logically isolated. - Multi-tenancy: The characteristic of cloud computing where multiple tenants share the same physical infrastructure while being kept logically separate. - Perimeter security: The first line of defence—fences, walls, guards, vehicle barriers. - Zero Trust Network Access (ZTNA): A security model that assumes no user or device is trusted by default, even if they are inside the network perimeter. This is a growing trend that the exam may reference. - Software-Defined Networking (SDN): A way to manage network services through software rather than physical hardware. Cloud networking is SDN-based. - Virtual Extensible LAN (VXLAN): A technology used to create isolated virtual networks in the cloud.

Critical exam strategy: When you read a question, first identify whether it is asking about physical or network security. Then ask: 'Is the responsibility mine or the provider's?' This two-step filter will eliminate most wrong answers immediately.

Key Takeaways

The Shared Responsibility Model splits security duties: the provider secures the infrastructure, and the customer secures everything they put into it.

Physical security for cloud data centres includes multi-layered controls such as perimeter fences, biometric access, CCTV, and environmental systems.

Network segmentation, using subnets and security groups, prevents an attacker who compromises one server from easily moving laterally to other servers.

Security groups are stateful, meaning if you allow inbound traffic, the reply is automatically allowed; network ACLs are stateless, requiring rules for both directions.

Encryption in transit (TLS) protects data moving across networks, while encryption at rest protects stored data, but neither replaces the need for firewalls and access controls.

A DMZ (Demilitarized Zone) places internet-facing servers in a separate subnet from internal systems to limit direct exposure.

Logging all network traffic (VPC Flow Logs) and API calls (e.g., CloudTrail) is essential for detecting and investigating security incidents.

The cloud provider is responsible for patching the hypervisor, but you are responsible for patching your virtual machine's operating system.

Easy to Mix Up

These come up on the exam all the time. Here's how to tell them apart.

Security Group

Stateful: automatically allows reply traffic.

Operates at the instance level.

Default deny all inbound, allow all outbound.

Network ACL (NACL)

Stateless: requires explicit rules for both directions.

Operates at the subnet level.

Default deny all inbound and outbound.

Cloud Provider Responsibility

Physical security of data centre.

Patching the hypervisor and network hardware.

Security of the cloud foundation (networking, storage, hypervisors).

Cloud Customer Responsibility

Patching the guest operating system and applications.

Configuring network security groups and ACLs.

Managing user access and encrypting data at rest and in transit.

Encryption in Transit

Protects data while it moves across networks (e.g., internet).

Uses protocols like TLS or IPSec.

Does not protect stored data if an attacker gains direct access to storage.

Encryption at Rest

Protects data when it is stored on disk or in a database.

Uses algorithms like AES-256.

Does not protect data during transmission between services.

Public Subnet

Has a route to the internet via an Internet Gateway.

Used for servers that need direct internet access (e.g., web servers).

Higher risk of exposure; requires tight security group rules.

Private Subnet

No direct route to the internet.

Used for internal servers (e.g., databases, application servers).

Lower risk; accessed through bastion hosts or NAT gateways.

Watch Out for These

Mistake

The cloud provider is responsible for all security in the cloud.

Correct

The cloud provider is responsible for security of the cloud (the physical data centre, the network infrastructure, and the hypervisor). The customer is responsible for security in the cloud (their operating systems, applications, data, and user access).

Beginners often assume 'the cloud' is a single entity that handles everything, just like a utility company. They do not grasp the Shared Responsibility Model, which is foundational to cloud security.

Mistake

If data is encrypted, I don't need to worry about network segmentation or firewalls.

Correct

Encryption protects data if it is intercepted, but it does not protect against attacks that exploit a vulnerability in a server or API. Firewalls and segmentation control who can even attempt to connect to a server, reducing the attack surface.

People hear that encryption is a powerful tool and assume it alone is sufficient. They do not realise that encryption does not stop an attacker from accessing a misconfigured server or stealing an API key that grants access to the encrypted data.

Mistake

Physical security is irrelevant in the cloud because you don't own the building.

Correct

Physical security is still critical because if an attacker gains physical access to a server, they can bypass most software-based controls. The cloud provider manages it, but the customer must verify the provider's physical security through certifications and audits.

The abstract nature of 'the cloud' makes people forget that hardware exists in a physical location. They think it's all 'virtual' and therefore not at risk from physical threats.

Mistake

A virtual private cloud (VPC) is a private, isolated physical piece of hardware.

Correct

A VPC is a logically isolated section of the cloud provider's shared, multi-tenant network. It is implemented in software, not hardware. Multiple customers' VPCs run on the same physical network infrastructure but are separated by virtualisation and encryption.

The term 'private' is misleading. Beginners think it means 'private hardware' rather than 'logically private' within shared infrastructure. This leads to misconceptions about isolation and security.

Do You Actually Know This?

Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.

Frequently Asked Questions

Do I need to visit the cloud provider's data centre to check their physical security?

No. You rely on independent audits like SOC 2 or ISO 27001 reports. These documents verify the provider's physical controls without you needing access.

What is the difference between a security group and a network ACL?

A security group is stateful (if you allow inbound, the reply is automatically allowed) and works at the instance level. A network ACL is stateless (you must define rules for both directions) and works at the subnet level.

Who patches the operating system on my virtual machine in the cloud?

You are responsible for patching the operating system (and your applications) inside your virtual machine. The cloud provider patches the hypervisor and the underlying host hardware.

Can I use the same firewall rules for all my cloud resources?

No. You should apply the principle of least privilege—grant only the minimum access necessary. Use different security groups for different tiers (web, app, database) so that compromise of one tier does not automatically expose others.

What is the purpose of a DMZ in cloud architecture?

A DMZ (Demilitarized Zone) is a subnet that houses servers accessible from the internet (like a website) while keeping internal servers isolated. If a server in the DMZ is compromised, the attacker still cannot directly reach backend databases.

Does enabling VPC Flow Logs affect performance?

No, VPC Flow Logs are collected outside the path of your network traffic, so they do not affect latency or throughput. They do incur a small storage cost, but that is usually negligible.

Terms Worth Knowing

Keep going

You've finished Cloud Platform and Infrastructure Security. Continue through the CCSP study guide to build a complete picture of the exam.

Done with this chapter?