11.4 Cloud Service Provider Governance & Shared Responsibility
Key Takeaways
- The Cloud Shared Responsibility Model establishes that the Cloud Service Provider (CSP) is responsible for 'Security OF the Cloud,' while the customer is strictly responsible for 'Security IN the Cloud.'
- In Infrastructure as a Service (IaaS), the customer controls the OS, middleware, runtime, and applications; in PaaS, the customer manages applications and data; in SaaS, the customer controls data, identity, and access configurations.
- Regardless of the cloud deployment model (IaaS, PaaS, SaaS) or service architecture, the customer ALWAYS retains 100% legal accountability for data classification, governance, and access control.
- Cloud Security Posture Management (CSPM) and Cloud Access Security Brokers (CASB) provide automated visibility, configuration drift detection, and data loss prevention across multi-cloud environments.
- Proactive cloud exit strategies mitigate vendor lock-in risk through containerization (Kubernetes), open APIs, infrastructure-as-code (IaC), and validated data extraction protocols.
11.4 Cloud Service Provider Governance & Shared Responsibility
Cloud computing has fundamentally revolutionized enterprise IT by replacing capital-intensive physical data centers with scalable, elastic, on-demand compute, storage, and software services. However, transitioning workloads to the cloud does not eliminate IT risk—it transforms the nature and distribution of that risk.
According to NIST SP 800-145 (The NIST Definition of Cloud Computing), cloud computing is characterized by five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. While these capabilities provide unmatched operational agility, they introduce complex multi-tenant governance, configuration drift, and shared security responsibilities that risk practitioners must master.
+-----------------------------------------------------------------------------+
| THE CLOUD SHARED RESPONSIBILITY MATRIX |
| |
| Layer / Component IaaS PaaS SaaS |
| ------------------------- ---------------- -------------- -------- |
| Data Classification & Gov [ CUSTOMER ] [ CUSTOMER ] [CUSTOMER]|
| Identity & Access (IAM) [ CUSTOMER ] [ CUSTOMER ] [CUSTOMER]|
| Application Logic & Code [ CUSTOMER ] [ CUSTOMER ] [ CSP ] |
| Middleware & Database Engine[ CUSTOMER ] [ CSP ] [ CSP ] |
| Operating System & Patching [ CUSTOMER ] [ CSP ] [ CSP ] |
| Hypervisor & Virtualization [ CSP ] [ CSP ] [ CSP ] |
| Physical Compute & Storage [ CSP ] [ CSP ] [ CSP ] |
| Physical Facilities/Power [ CSP ] [ CSP ] [ CSP ] |
| |
| *UNIVERSAL GOVERNANCE RULE: The CUSTOMER is ALWAYS 100% responsible for |
| Data Governance, Information Classification, and Access Management! |
+-----------------------------------------------------------------------------+
1. Cloud Service Models: Control vs. Delegation
The boundary of security responsibility shifts dramatically depending on the cloud service delivery model:
A. Infrastructure as a Service (IaaS)
- Architecture: The CSP provides virtualized hardware resources—compute (virtual machines), block/object storage, and software-defined networking.
- Customer Responsibility: The customer exercises extensive control and bears substantial security responsibility. The customer must configure, harden, and patch the guest Operating System (OS), configure firewall rules (Security Groups / Network Access Control Lists), manage database engines, install middleware, secure application code, and configure IAM policies.
- CSP Responsibility: Physical data center security, environmental controls, physical server hardware, power, cooling, and the virtualization hypervisor layer.
- Examples: Amazon Web Services (EC2/EBS), Microsoft Azure (Virtual Machines), Google Cloud Platform (Compute Engine).
B. Platform as a Service (PaaS)
- Architecture: The CSP abstracts away the underlying operating system, server hardware, and runtime environment, providing a turnkey platform for developers to deploy code and manage databases.
- Customer Responsibility: Developing, securing, and maintaining the application code, configuring database schemas and queries, and managing user authentication and access controls.
- CSP Responsibility: Patching and maintaining the underlying OS, runtime environment (e.g., Node.js, Python, Java runtime), database management engine, hypervisor, physical infrastructure, and network routing.
- Examples: AWS Elastic Beanstalk, Google App Engine, Azure App Services, Snowflake, Amazon RDS.
C. Software as a Service (SaaS)
- Architecture: The CSP delivers a complete, fully managed software application accessed over the internet (typically via web browser or API).
- Customer Responsibility: Data governance, data classification, configuring user access rights (IAM / Single Sign-On / MFA), setting organizational security policies within the tenant, and preventing data loss.
- CSP Responsibility: Everything else—application development, vulnerability remediation, patching, backend database administration, infrastructure scaling, uptime, and physical data center security.
- Examples: Microsoft 365, Salesforce, Workday, ServiceNow, Google Workspace.
2. Cloud Deployment Models & Governance Implications
+-----------------------------------------------------------------------------+
| CLOUD DEPLOYMENT TOPOLOGIES |
| |
| Deployment Model Infrastructure Ownership Multi-Tenancy / Isolation |
| ---------------- --------------------------- ------------------------- |
| Public Cloud Owned & operated by CSP Multi-tenant; shared |
| (AWS, Azure, GCP) physical infrastructure |
| ------------------------------------------------------------------------- |
| Private Cloud Operated exclusively for a Single-tenant; dedicated |
| single enterprise isolated infrastructure |
| ------------------------------------------------------------------------- |
| Hybrid Cloud Composition of two or more Bound by standardized |
| distinct clouds (Priv/Pub) technology (APIs / VPN) |
| ------------------------------------------------------------------------- |
| Community Cloud Shared by organizations with Multi-tenant across a |
| common mission / compliance restricted trusted group |
+-----------------------------------------------------------------------------+
3. Automated Cloud Governance & Security Tooling
Because cloud environments are dynamic, API-driven, and subject to rapid continuous deployment, traditional static security audits are insufficient. Organizations deploy automated cloud governance tooling:
+-----------------------------------------------------------------------------+
| CLOUD SECURITY TOOLING ECOSYSTEM |
| |
| [CSPM: Cloud Security Posture Management] |
| - Continuously scans cloud infrastructure (IaaS/PaaS) for misconfiguration|
| - Identifies open S3 buckets, overly permissive IAM roles, unencrypted db|
| - Benchmarks configurations against CIS Foundations & NIST frameworks |
| |
| [CWPP: Cloud Workload Protection Platform] |
| - Protects workloads (VMs, containers, Kubernetes, serverless functions) |
| - Runtime threat detection, container image scanning, eBPF telemetry |
| |
| [CASB: Cloud Access Security Broker] |
| - Sits between enterprise users and SaaS cloud applications (inline / API)|
| - Enforces Data Loss Prevention (DLP), detects Shadow IT, mandates MFA |
| |
| [CIEM: Cloud Infrastructure Entitlement Management] |
| - Enforces least privilege across complex multi-cloud IAM permissions |
| - Identifies over-permissioned service accounts & inactive roles |
+-----------------------------------------------------------------------------+
The Anatomy of a Cloud Misconfiguration Breach:
Industry data indicates that over 95% of cloud security breaches are caused by customer misconfigurations, not vulnerabilities in the underlying CSP hypervisor. Common catastrophic failures include:
- Publicly Exposed Object Storage: Leaving cloud storage buckets (e.g., AWS S3, Azure Blob) set to public read access without authentication.
- Overly Permissive IAM Roles: Granting administrative (
*:*) wildcard privileges to compute instances or lambda functions, allowing Server-Side Request Forgery (SSRF) attacks to steal temporary security credentials via the Instance Metadata Service (IMDS). - Unrestricted Ingress Ports: Exposing database ports (e.g., MySQL 3306, PostgreSQL 5432) or management ports (RDP 3389, SSH 22) directly to
0.0.0.0/0(the entire internet).
4. Vendor Lock-In & Cloud Exit Strategies
A critical risk in long-term cloud governance is vendor lock-in—a situation where an enterprise becomes so technologically and financially dependent on a specific cloud provider that transitioning to another provider or repatriating workloads on-premises is cost-prohibitive or technically infeasible.
+-----------------------------------------------------------------------------+
| CLOUD LOCK-IN & EXIT STRATEGY MODEL |
| |
| Lock-In Drivers / Traps Exit Strategy Architectural Controls |
| ---------------------------------- ------------------------------------ |
| Proprietary APIs & Specialized Adopt Containerization (Docker, OCI) |
| Services (e.g., DynamoDB, BigQuery) and Orchestration (Kubernetes / K8s) |
| ------------------------------------------------------------------------- |
| High Egress Bandwidth Fees Architect open, non-proprietary data |
| (Financial barriers to moving data) formats (Parquet, JSON) & multi-CDN |
| ------------------------------------------------------------------------- |
| Proprietary Infrastructure Scripts Use Multi-Cloud Infrastructure as |
| (e.g., AWS CloudFormation) Code (IaC: Terraform / OpenTofu) |
| ------------------------------------------------------------------------- |
| Untested Migration Playbooks Mandate annual dry-run exit drills & |
| contractual data extraction SLAs |
+-----------------------------------------------------------------------------+
Essential Elements of a Defensible Cloud Exit Plan:
- Data Portability: Ensure all enterprise data is stored in standard, non-proprietary formats that can be exported without vendor transformation tools.
- Infrastructure-as-Code (IaC) Portability: Avoid proprietary CSP orchestration templates; standardize on open-source, multi-cloud declarative tools (such as Terraform or OpenTofu).
- Decoupled Architecture: Encapsulate application logic in standardized Open Container Initiative (OCI) containers and deploy across managed Kubernetes environments.
- Contractual Exit Assistance: Mandate that the CSP contractually commit to providing operational and technical data extraction assistance at predefined hourly rates upon contract termination.
5. CSP Assurance & Certification Frameworks
To validate that a CSP operates defensible controls over its physical and hypervisor infrastructure, risk practitioners evaluate recognized cloud assurance artifacts:
- ISO/IEC 27017: Code of practice for information security controls based on ISO/IEC 27002 specifically for cloud services.
- ISO/IEC 27018: Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors.
- FedRAMP (Federal Risk and Authorization Management Program): Rigorous U.S. government standard assessing CSP security across Low, Moderate, and High impact baselines based on NIST SP 800-53.
- CSA STAR Level 2: Independent third-party attestation combining SOC 2 Type II audits with the CSA Cloud Controls Matrix (CCM).
6. CRISC Exam Traps & Real-World Scenarios
Exam Trap 1: Believing SaaS Outsources Data Governance and Privacy Liability
- The Trap: An organization transitions to a SaaS CRM platform and assumes that because the CSP manages the software, the CSP is legally responsible for customer data breaches.
- The Reality: Under the Shared Responsibility Model and statutory data protection laws (GDPR, HIPAA, CCPA), the data owner (customer) ALWAYS retains 100% legal accountability for data classification, authorized user access, and privacy compliance.
Exam Trap 2: Confusing IaaS Operating System Patching with PaaS
- The Trap: A question describes an unpatched vulnerability in the underlying Linux OS of an Amazon EC2 or Azure VM instance that leads to a breach. The candidate assumes the cloud provider failed their patching duty.
- The Reality: In IaaS, the customer is strictly responsible for configuring, updating, and patching the guest operating system. In PaaS, the CSP is responsible for OS and runtime patching.
Exam Trap 3: Assuming Cloud Providers Automatically Back Up Customer Data
- The Trap: A company loses a critical database due to an administrator error and requests that the IaaS provider restore yesterday's backup. The provider states that no backup exists.
- The Reality: IaaS and PaaS providers guarantee infrastructure availability, not automated customer data backup, unless the customer has explicitly configured, scheduled, and funded backup/replication services.
An enterprise migrates its customer relationship management (CRM) database to a public Software-as-a-Service (SaaS) platform. An employee with administrative privileges fails to configure multi-factor authentication (MFA) on their account and falls victim to a credential-harvesting phishing attack. The adversary uses the stolen credentials to log in to the SaaS portal and exfiltrates 100,000 sensitive customer records. Under the Cloud Shared Responsibility Model and enterprise risk governance baselines, who bears ultimate responsibility for this data breach?
An enterprise risk practitioner is evaluating security controls across the organization's multi-cloud environment consisting of multiple Amazon Web Services (AWS) and Microsoft Azure subscriptions. The security operations team needs an automated solution that can continuously scan cloud infrastructure configurations, detect publicly exposed storage buckets, identify unencrypted databases, and benchmark security settings against CIS Foundations baselines. Which technology is best suited to satisfy this requirement?
A multinational corporation is designing an enterprise cloud strategy to migrate mission-critical transactional workloads to an Infrastructure as a Service (IaaS) provider. Executive leadership expresses deep concern regarding vendor lock-in, noting that proprietary cloud provider architectures could prevent the company from easily transitioning workloads in the future if pricing increases or performance degrades. Which architectural approach best mitigates this risk?
An enterprise risk practitioner is assessing a Tier 1 cloud service provider's security and compliance posture for hosting healthcare data subject to HIPAA regulations. The CSP provides a Cloud Security Alliance (CSA) Security, Trust, Assurance and Risk (STAR) Level 2 attestation. What does a CSA STAR Level 2 attestation represent in terms of audit rigor and independent verification?