2.3 Cloud Deployment Models & Shared Responsibility in Practice

2.3 Cloud Deployment Models & Shared Responsibility in Practice

Quick Answer: NIST SP 800-145 defines four cloud deployment models: Public, Private, Hybrid, and Community. The foundational security principle uniting all cloud operations is the Shared Responsibility Model: the Cloud Service Provider (CSP) is responsible for the security OF the cloud (physical facilities, hardware, hypervisors), while the customer is responsible for the security IN the cloud (data, IAM, network rules, OS patching in IaaS). The customer retains accountability for its data use, tenant identity decisions, and applicable obligations, while operational tasks can shift to the provider. The exact division comes from the service model, configuration, contract, and provider documentation.

---

The 4 NIST Cloud Deployment Models

Cloud deployment models define the relationship between the infrastructure, who owns and operates it, and who is permitted access to consume its resources.

                               +---------------------------------+
                               |     NIST DEPLOYMENT MODELS      |
                               +---------------------------------+
                                 /       |             |        \
                                /        |             |         \
                               v         v             v          v
                        [ Public ]  [ Private ]   [ Community ] [ Hybrid ]

1. Public Cloud

In a Public Cloud, the cloud infrastructure is provisioned for open, multi-tenant use by the general public, enterprises, and government agencies. It is owned, managed, and operated by a commercial cloud service provider (such as Amazon Web Services, Microsoft Azure, or Google Cloud Platform).

• Key Characteristics: Massive economies of scale, near-infinite rapid elasticity, global availability zones, pay-as-you-go billing.
• Security Realities: Multi-tenancy isolation is enforced logically via hypervisors and software-defined networks. Customers cannot physically inspect data centers and must rely on independent third-party audit reports (such as SOC 2 Type II, ISO/IEC 27001, and CSA STAR).

2. Private Cloud

In a Private Cloud, the infrastructure is provisioned for exclusive use by a single organization comprising multiple internal business units. It can be owned, managed, and operated by the organization itself, a third-party managed service provider, or a combination.

• Deployment Variations:
  • On-Premises Private Cloud: Hosted inside the organization's own physical data center. Offers maximum physical control and data sovereignty, but incurs heavy CapEx, hardware refresh costs, and capacity bounds.
  • Hosted / Managed Private Cloud: Hosted off-site in a provider's data center on dedicated, single-tenant hardware leased exclusively to the organization.
• Security Realities: Eliminates multi-tenant "noisy neighbor" risks and external hypervisor co-tenancy. However, the organization bears the burden of physical hardware maintenance, hypervisor patching, and high disaster-recovery overhead.

3. Community Cloud

In a Community Cloud, the infrastructure is provisioned for exclusive use by a specific community of consumers from organizations that have shared missions, common security baselines, regulatory compliance mandates, or technical policies.

• Typical Communities: Healthcare research consortiums sharing genomic datasets, municipal government agencies within a state, defense industrial base contractors, or financial transaction processing networks.
• Ownership & Operation: May be owned, managed, and operated by one or more member organizations, a commercial third party, or a public-private partnership.
• Security Realities: Provides the economic sharing benefits of multi-tenancy while restricting tenancy strictly to known, vetted community participants who adhere to identical compliance standards.

4. Hybrid Cloud

A Hybrid Cloud is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology enabling data and application portability.

• Common Hybrid Architectural Patterns:
  • Cloud Bursting: An organization runs its baseline web application in an on-premises private cloud. When seasonal demand spikes exceed local capacity, the application automatically "bursts" additional stateless web nodes into a public cloud to handle excess traffic.
  • Tiered Data Partitioning: An organization keeps sensitive customer financial records in a secure on-premises private cloud database, while hosting the public-facing e-commerce web application in a public cloud.
  • Hybrid Disaster Recovery (DR): Primary production systems run on-premises, while an automated failover replication target is maintained in a public cloud, ready to activate upon primary site disruption.
• Technical Requirements: Secure, high-speed interconnects (IPsec VPN tunnels or dedicated carrier connections like AWS Direct Connect or Azure ExpressRoute), unified identity federation (SAML 2.0 / OpenID Connect), and centralized security policy orchestration.

---

Modern Cloud Strategies: Multi-Cloud & Sovereign Clouds

Multi-Cloud Architecture

Organizations increasingly deploy workloads across multiple independent public cloud providers (e.g., AWS, Azure, and GCP simultaneously):

• Drivers: Preventing single-vendor lock-in, optimizing pricing via commercial leverage, utilizing specialized best-of-breed services (e.g., GCP for machine learning, Azure for Active Directory integration, AWS for mature serverless capabilities), and satisfying regulatory mandates (such as the European Union DORA directive requiring financial institutions to maintain exit and multi-vendor resilience strategies).
• Operational Challenges: Fragmented identity policies across cloud consoles, incompatible logging and telemetry formats, duplicate CI/CD deployment pipelines, network interconnect latency, and massive cross-cloud data egress fees.

Sovereign Clouds

Geopolitical tensions and data privacy laws have accelerated the development of Sovereign Clouds:

• Regulatory Drivers: National data sovereignty legislation, the European Union General Data Protection Regulation (GDPR Chapter V international transfers), the NIS2 directive, and concerns regarding extraterritorial access by foreign governments under the United States CLOUD Act (Clarifying Lawful Overseas Use of Data Act).
• Architectural Safeguards:
  • Physical data center facilities located strictly within the national territory.
  • Operational control and technical support restricted exclusively to vetted domestic citizens possessing national security clearances.
  • Cryptographic sovereignty: Encryption keys managed under a Hold Your Own Key (HYOK) architecture, hosted in on-premises Hardware Security Modules (HSMs) completely isolated from the foreign cloud service provider.

---

The Shared Responsibility Model: Mechanics & Invariants

The Shared Responsibility Model is the foundational operating framework for all cloud security. It establishes an explicit dividing line between the security obligations of the Cloud Service Provider and those of the Cloud Service Customer.

+-----------------------------------------------------------------------------------+
|                     SECURITY IN THE CLOUD (Customer Responsibility)               |
|   - Customer Data & Data Classification                                            |
|   - Identity and Access Management (IAM, MFA, Role Assignment)                    |
|   - Application Source Code & API Security                                         |
|   - Operating System Patching & Host Firewalls (IaaS)                             |
|   - Virtual Network Routing & Security Group Rules (IaaS/PaaS)                    |
+===================================================================================+
|                      THE SHARED RESPONSIBILITY DIVIDING LINE                      |
+===================================================================================+
|                     SECURITY OF THE CLOUD (CSP Responsibility)                    |
|   - Physical Data Center Security (Perimeters, Biometrics, Guards)                |
|   - Environmental Controls (Power Grids, Generators, HVAC Chillers)               |
|   - Hardware Infrastructure (Physical Servers, Fiber Optics, SAN Disks)           |
|   - Hypervisor Virtualization & Core SDN Infrastructure                           |
+-----------------------------------------------------------------------------------+

The Core Rule: Security OF the Cloud vs. Security IN the Cloud

• Security OF the Cloud (Provider Responsibility): The provider is responsible for protecting the infrastructure that runs all of the services offered in the cloud. This includes the physical facilities, hardware servers, disk arrays, network cables, hypervisor software, and core control-plane management services.
• Security IN the Cloud (Customer Responsibility): The customer is responsible for the configuration and operation of the services they provision. This includes customer data, identity and access management, operating system configuration and patching (in IaaS), firewall configuration, and application security.

Persistent Customer Accountabilities

Across IaaS, PaaS, and SaaS, customers normally retain governance decisions even when a provider performs much of the underlying operation:

1. Data Governance & Classification: The customer determines permitted data use, classification, and applicable requirements. Ownership and legal roles depend on contracts and law.
2. Identity & Access Management (IAM): The provider secures the IAM service; the customer governs tenant users, federation, role assignments, and security options exposed by that service.
3. Endpoint Security: The customer generally governs the endpoints and access conditions used by its workforce, while managed desktop or device services can shift selected operations to a provider.
4. Compliance Accountability: The customer is legally and contractually accountable to regulatory authorities (HIPAA, PCI-DSS, GDPR, SEC) for protecting sensitive consumer data.

---

Comprehensive Shared Responsibility Matrix

---

Real-World Failure Modes in Practice

Industry consensus across CSA, Gartner, and major incident response firms indicates that more than 95% of cloud security failures are the customer's fault, stemming from configuration errors rather than CSP infrastructure breaches.

1. Customer Misconfigurations (Real-World Examples)

• Publicly Accessible Object Storage Buckets: Administrators misconfigure cloud storage permissions (e.g., setting AWS S3 bucket ACLs to AllUsers or AuthenticatedUsers), exposing millions of unencrypted customer records, database backups, and internal logs to the public internet.
• Permissive Security Groups: Engineers open administrative ports—such as Port 22 (SSH) or Port 3389 (RDP)—to the entire internet (0.0.0.0/0), allowing automated internet scanning bots to brute-force credentials or execute remote code.
• Hardcoded API Credentials: Developers inadvertently commit cloud provider access keys and secret tokens into public GitHub repositories. Automated scanning bots harvest these credentials within seconds to deploy unauthorized cryptocurrency-mining compute instances.
• Absence of Multi-Factor Authentication (MFA): Cloud root accounts or administrative console logins lacking MFA are compromised through credential-stuffing attacks, allowing adversaries to delete entire cloud production environments.

2. Provider Outages and Blast Radius

While CSP infrastructure breaches are extremely rare, provider outages do occur:

• Control-Plane Failures: A failure in a provider's centralized API management or IAM service can prevent customers from spinning up, terminating, or modifying virtual instances, even if running compute nodes remain healthy.
• Availability Zone Power / Fiber Disruption: Severe weather or construction accidents can take down an entire availability zone. Workloads that were not engineered for multi-AZ redundancy experience catastrophic downtime.
• The SLA Credit Reality: Cloud Service Level Agreements (SLAs) strictly limit provider liability. If a provider experiences an unscheduled 12-hour regional outage, the contractual remedy is almost exclusively a percentage service credit on the customer's monthly bill. Standard provider terms commonly limit outage remedies to service credits and exclude consequential damages, but negotiated contracts, insurance, and applicable law can change that allocation.

[!CAUTION] The "Assurance Inheritance Fallacy": Many enterprises falsely assume that because an IaaS provider holds FedRAMP High, ISO/IEC 27001, and PCI-DSS Level 1 certifications, their own application running inside that IaaS environment is automatically compliant. This is completely false. The provider's certification validates only the physical data centers, hardware, and hypervisor (Security OF the Cloud). The customer must independently implement, configure, and audit the operating system, network rules, code, and data encryption to achieve regulatory compliance.