1

Cloud Deployment Models — Public, Private, Community, Hybrid & Multi-Cloud

A cloud deployment model classifies the ownership and management of the cloud — who controls the infrastructure and who shares it. Each model involves a different trade-off between security, cost, and control.

Public Cloud
Multi-tenant / Shared
Resources available to any paying customer. Multiple independent tenants share physical hardware with logical separation. Examples: AWS, Microsoft Azure, Google Cloud. Provider = integrity + availability of platform. Consumer = confidentiality, authorisation, authentication. Pay-per-use — most cost-effective. Least control over physical hardware.
Private Cloud
Single-tenant
One organisation exclusively uses the cloud infrastructure. Can be hosted internally (in your own offices) or externally (contracted facility). Example: AWS GovCloud — US government exclusive. More secure but more expensive — pay for 100% capacity even when using 50%. Full control from software to hardware.
Community Cloud
Shared by cooperating tenants
Resources shared among organisations with a common service need (e.g. multiple banks sharing a cloud for regulatory compliance). Cost and responsibility shared across members. Risk: security must be negotiated to a common denominator. Requires strong interoperability agreements. Weak member = vulnerability for all.
Hybrid Cloud
Mixed environment
Combines public + private + community + on-premise. Sensitive data in private cloud, public-facing services in public cloud. More complex — requires orchestration tools, careful redundancy planning, compliance demonstration across both environments, and unified identity/access management.
Multi-Cloud
Multiple public cloud services
Using multiple public cloud providers simultaneously (AWS + Azure + Google + Slack + Zoom + M365). Very common for organisations. Increases complexity and requires additional risk assessment per provider. Each service adds a new attack surface and compliance scope.
Exam identification guide: "Company uses AWS/Azure/Google" = public cloud. "Company builds its own cloud" = private. "Several banks share a cloud" = community. "Financial data on private, website on public" = hybrid. "Using Slack + Zoom + AWS + M365" = multi-cloud. Know the security/cost trade-offs: more security → private; more flexibility/lower cost → public. Community clouds need strong interoperability agreements or the weakest member is everyone's vulnerability.
2

Cloud Service Models — IaaS, PaaS, SaaS & SECaaS

Cloud service models classify what the cloud provider gives you and where your responsibility begins. The dividing line between vendor and consumer responsibility is the critical concept — and it shifts dramatically across these three models.

Responsibility stack — where vendor ends, consumer begins

Service Model Responsibility Stack — Coloured = Consumer; Grey = Vendor-managed
IaaS
Applications
Data
Runtime
Middleware
OS (consumer manages)
Virtualisation
Servers
Storage
Networking
PaaS
Applications
Data
▲ Consumer codes above here
Runtime
Middleware
OS (vendor patches)
Virtualisation
Servers
Storage
Networking
SaaS
Data (your own)
Authorisation & accounts
▲ Consumer manages above
Applications
Runtime
Middleware
OS
Virtualisation
Servers
Networking
🟧 IaaS consumer = OS up (most responsibility) 🟦 PaaS consumer = application + data only 🟩 SaaS consumer = data + authorisation only (least responsibility) ⬜ Grey = vendor-managed in all three

Service model details

IaaS — Infrastructure as a Service
Most consumer responsibility
Vendor provides: hardware, networking, storage, virtualisation. Consumer gets a base OS and does everything above it — installs middleware, runtime, databases, web server (Apache/IIS), and builds the application. Provider ensures CIA of the hardware resource pool. Consumer responsible for security of OS and everything above. Risk: VM sprawl, cost overruns if VMs aren't governed. Examples: AWS EC2, Azure VMs, Google Compute.
PaaS — Platform as a Service
Middle ground
Vendor provides everything from hardware through middleware and runtime — including an OS that's kept patched and secure. Consumer focuses only on building and deploying the application and managing their data. Encrypt data — the PaaS provider controls the underlying database. Access control, load balancing, failover = consumer responsibility (coded into the application). Examples: AWS Elastic Beanstalk, Heroku, managed WordPress.
SaaS — Software as a Service
Least consumer responsibility
Vendor provides the complete application stack — hardware through app. Consumer is responsible only for their data (what they input) and for account provisioning/authorisation. Security of the code = provider's problem (XSS, SQL injection in the app = vendor issue). Loss of credentials from your employee's computer = consumer's problem. Examples: Office 365, Google Workspace, Slack, QuickBooks Online.
SECaaS — Security as a Service
For analysts
Provides security services without an in-house cybersecurity staff. Covers: anti-malware, incident response, encryption services, monitoring, logging, anti-spam. Cloud-based security products benefit from AI/machine learning (requires massive compute that most orgs don't own). Career note: SECaaS providers are major employers of cybersecurity analysts.
3

Cloud Infrastructure — VPC, Cloud vs. On-Premise

Virtual Private Cloud (VPC)

A VPC is a private network segment within a public cloud, making resources available exclusively to a single cloud consumer. It's an IaaS product. Think of it as having your own private subnet inside AWS or Azure, isolated from other tenants using VLANs and virtual networking.

What VPC provides
Provision virtual servers, appliances, and networking within a virtual network hosted on a public cloud. Consumer controls IP address space and routing. Equivalent to running your own network, but on someone else's hardware. Good alternative to a full private cloud at lower cost.
VPC limitations
Not as secure as a true private cloud — still on shared physical hardware. Data remnants can persist on servers between provisioning/deprovisioning. But from a networking and privacy perspective, protection is equivalent to a private network.
Consumer responsibility in VPC
Everything: IP address space, routing, software installation, patching, account management, load balancing, disaster recovery, security monitoring, backups. The only difference from owning physical servers is you don't have physical access or need to handle hardware failures.

Cloud vs. on-premise

Cloud benefits
Infinitely scalable. Pay-per-use (no wasted capacity). No hardware to buy or maintain. No late-night hardware failure calls. Global presence for redundancy. Enables AI/ML integration for security tools (cloud has the massive compute they require).
On-premise benefits
Full physical control of hardware. Data never leaves your facility (meets some compliance requirements). No dependency on internet connectivity. No vendor lock-in risk. Can customise hardware completely. Suitable when regulatory rules prohibit cloud storage of certain data types.
Vendor lock-in risk
Moving large volumes of data from one cloud to another (or back to on-premise) can cost hundreds of thousands of dollars in bandwidth and usage fees. Always evaluate: what will it cost to leave this provider? Low upfront costs often come with expensive exit paths. Design exit strategies before committing.
Compliance considerations
Some regulations require data to stay in specific countries or jurisdictions (data sovereignty). Some industries prohibit certain data types being stored in shared public cloud environments. Always verify regulatory requirements before choosing a cloud deployment model.
4

CASB — Cloud Access Security Broker

A Cloud Access Security Broker (CASB) is enterprise management software that mediates access to cloud services by users across all device types. It sits between cloud service consumers and providers, enforcing security policies, monitoring usage, and providing visibility into how cloud services are being used.

CASB capabilities

Single sign-on (SSO)
Enables SSO authentication across all cloud services. Enforces access controls and authorisation policies from the enterprise network through to cloud providers — one credential set, consistent enforcement everywhere.
Malware and rogue device scanning
Scans traffic and devices attempting to access cloud services. Detects malware in files being uploaded or downloaded. Identifies rogue or non-compliant devices attempting to access corporate cloud services.
User and resource activity monitoring
Monitors and audits exactly what users are doing with cloud services — what data is accessed, how much time is spent, where data is sent. Provides visibility into Shadow IT (cloud services being used without IT approval).
Data exfiltration mitigation (DLP)
Functions as a cloud-aware Data Loss Prevention system. Detects and blocks sensitive data from being uploaded to unauthorised cloud services or transferred to personal accounts. Enforces DLP policies as data crosses the cloud boundary.

Three CASB deployment methods

→
Forward Proxy
Security appliance at the client network edge. User traffic is routed through the proxy before it reaches the cloud. The CASB sits between the user and the internet and can inspect, log, and block traffic based on policy.
⚠ Risk: Users can bypass by directly connecting to the internet, evading the proxy. A knowledgeable user can reconfigure their browser to skip it.
←
Reverse Proxy
Security appliance at the cloud network edge (not the client edge). Users can leave your network freely, but they can't access the cloud service without passing through the CASB. Traffic is inspected as it enters the cloud.
⚠ Limitation: Only works if the cloud application supports proxy configurations. Not all cloud services support this deployment mode.
⇄
API Access
Uses the cloud service's API to directly communicate policy changes. When a user account is disabled locally (e.g. terminated employee), the CASB sends an API call to the cloud service to revoke access immediately. No traffic proxying required.
⚠ Limitation: Only works if the cloud service's API supports the specific policy functions you need. Complex or granular policies may not be supported.

CASB vendors

Symantec
Blue Coat proxy — widely deployed enterprise CASB and web filtering solution. One of the most established products in the enterprise security space.
McAfee — Skyhigh Networks
Acquired Skyhigh Networks to build its cloud security offering. Strong DLP integration and cloud visibility capabilities.
Forcepoint
Enterprise CASB with strong data protection, user behaviour analytics, and insider threat detection capabilities.
Microsoft MCAS
Microsoft Cloud App Security — tightly integrated with the Microsoft 365/Azure ecosystem. Native visibility into Microsoft cloud services and third-party SaaS applications.
Cisco CloudLock
Cisco's cloud-native CASB. API-based approach focusing on data security, user security, and threat protection for cloud applications.
Exam

Quick Reference Cheat Sheet

Cloud deployment models (5)
Public = multi-tenant, shared hardware, pay-per-use (AWS/Azure/Google). Private = single-tenant, full control, most secure, most expensive (AWS GovCloud). Community = shared by orgs with common needs, cost-shared, weakest member = everyone's risk. Hybrid = mix of public + private + on-premise, more complex. Multi-cloud = multiple public cloud services (Slack + Zoom + M365 + AWS). Know: security need → private. Cost priority → public.
Service models (IaaS/PaaS/SaaS)
IaaS = vendor gives hardware+virtualisation+networking. Consumer manages: OS, middleware, runtime, apps, data. Most consumer work. PaaS = vendor gives hardware through middleware+runtime+OS. Consumer manages: application code + data. Middle ground. SaaS = vendor gives everything through the application. Consumer manages: their data + user accounts. Least consumer work. XSS/SQL injection in Office 365 = Microsoft's fault (SaaS). Employee loses credentials = consumer's fault.
SECaaS & cloud infrastructure
SECaaS = Security as a Service. Provides anti-malware, IR, monitoring, logging without in-house staff. Benefits from cloud AI/ML compute. Career path: SECaaS companies hire cybersecurity analysts. VPC = Virtual Private Cloud — private network segment within a public cloud (IaaS product). Consumer controls IP space, routing, and all software. Not as secure as true private cloud (shared physical hardware) but networking equivalent. Vendor lock-in = expensive to leave (evaluate exit costs upfront).
CASB — Cloud Access Security Broker
Enterprise software mediating access between cloud consumers and providers. Capabilities: SSO enforcement, malware/rogue device scanning, user activity monitoring, DLP (data exfiltration prevention). 3 deployment methods: Forward Proxy (client edge, bypassable by savvy users), Reverse Proxy (cloud edge, requires cloud app proxy support), API (direct API calls to cloud service — revoking accounts etc., limited by API capabilities). Vendors: Symantec Blue Coat, McAfee Skyhigh, Forcepoint, Microsoft MCAS, Cisco CloudLock.
Cloud vs. on-premise tradeoffs
Cloud: scalable, pay-per-use, no hardware maintenance, enables AI/ML, global redundancy. Drawbacks: vendor lock-in, data sovereignty concerns, compliance limits, dependent on internet. On-premise: physical control, data stays in facility, no vendor dependency. Drawbacks: capital expense, hardware failures = your problem, limited scalability. Choose cloud when: scalability, cost efficiency, AI/ML. Choose on-premise when: data sovereignty, strict compliance, need for physical control. Hybrid = financial data on-premise/private, customer-facing on public.