Cloud Security Fundamentals

Cloud security fundamentals encompass the policies, controls, technologies, and shared responsibilities that protect data, applications, and infrastructure deployed in cloud environments. This page covers the definitional scope of cloud security, the mechanisms through which controls are applied, the operational scenarios where cloud security decisions arise, and the boundaries that determine which security obligations fall to cloud providers versus cloud customers. These fundamentals apply across infrastructure-as-a-service (IaaS), platform-as-a-service (PaaS), and software-as-a-service (SaaS) deployment models as defined by NIST SP 800-145.

Definition and scope

Cloud security is the discipline of applying cybersecurity controls to computing environments hosted on shared, remotely accessible infrastructure managed by third-party providers. The scope is defined by three service models and four deployment models. The three service models — IaaS, PaaS, and SaaS — determine which layers of the stack a customer controls and therefore which security obligations belong to the customer. The four deployment models — public, private, hybrid, and community cloud — define the boundary of who shares the underlying infrastructure.

NIST SP 800-144, Guidelines on Security and Privacy in Public Cloud Computing, establishes the authoritative scope framework for US federal and industry reference. It identifies seven categories of security concern specific to cloud environments: governance, compliance, trust, architecture, identity, data protection, and incident response.

The Federal Risk and Authorization Management Program (FedRAMP) operationalizes cloud security scope for federal agencies, requiring cloud service providers to obtain an authorization to operate (ATO) against a baseline derived from NIST SP 800-53. FedRAMP recognizes three impact baselines — Low, Moderate, and High — corresponding to the potential harm of a security breach on federal operations. The cloud security providers available through this provider network organize providers in part by these service model categories.

How it works

Cloud security operates through a layered control architecture distributed between the cloud service provider (CSP) and the customer under the shared responsibility model. The precise division of responsibility shifts depending on the service model:

1. IaaS — The CSP secures physical facilities, networking hardware, and the hypervisor layer. The customer is responsible for the operating system, middleware, runtime, applications, and data.
2. PaaS — The CSP additionally manages the operating system and runtime. The customer retains responsibility for applications, data, and access management.
3. SaaS — The CSP manages all infrastructure layers and the application itself. The customer's primary security obligations concentrate on identity and access management, data classification, and configuration of application-level security settings.

Across all three models, identity and access management (IAM) remains a customer-controlled domain. The Cloud Security Alliance (CSA) publishes the Security Guidance for Critical Areas of Focus in Cloud Computing (v4.0), which structures cloud security implementation across 14 domains including governance, risk management, data security, and application security.

Control implementation follows a phased operational sequence:

1. Asset discovery and classification — Cloud resources are inventoried; data is classified by sensitivity.
2. Threat modeling — Attack surfaces specific to the cloud environment are mapped against threat vectors.
3. Control selection and mapping — Security controls are selected from a recognized framework such as NIST SP 800-53 or the CSA Cloud Controls Matrix (CCM).
4. Continuous monitoring — Automated tooling (including Cloud Security Posture Management platforms) detects configuration drift and policy violations.
5. Incident response — Predefined runbooks govern detection, containment, and recovery in cloud-native environments.

The section of this site provides additional context on how providers operating across these phases are categorized.

Common scenarios

Cloud security fundamentals apply across four recurring operational scenarios:

Misconfiguration exposure — Publicly accessible storage buckets, permissive IAM roles, and disabled logging represent the most frequently observed cloud vulnerability class. The CSA 2024 State of Cloud Security report identifies misconfiguration as a top contributor to cloud-related data incidents.

Compliance scope determination — Organizations subject to HIPAA (administered by the HHS Office for Civil Rights), PCI DSS (governed by the PCI Security Standards Council), or FISMA (OMB Circular A-130) must map cloud environments to applicable control requirements before deployment.

Multi-cloud and hybrid environments — Organizations operating across two or more CSPs face fragmented visibility and inconsistent control implementation. Unified policy enforcement requires abstraction layers such as a Cloud Access Security Broker (CASB).

Supply chain and third-party risk — Cloud-native applications routinely consume third-party APIs, container images, and open-source libraries. Each integration point extends the attack surface beyond the primary CSP relationship.

Decision boundaries

The central decision boundary in cloud security is the shared responsibility line: control obligations that belong to the CSP by contract cannot be assumed by the customer, and obligations retained by the customer cannot be delegated to the CSP without explicit contractual and technical verification.

A secondary boundary distinguishes preventive controls (IAM policies, network segmentation, encryption at rest) from detective controls (log aggregation, anomaly detection, configuration scanning). Effective cloud security programs require both categories; reliance on detective controls alone is an architectural deficiency, not a compensating strategy.

A third boundary separates cloud-native security tooling (services integrated into a CSP's platform, such as AWS GuardDuty or Azure Defender) from third-party or agnostic tooling that operates across providers. Cloud-native tools offer lower integration friction but introduce CSP lock-in and may lack portability in multi-cloud architectures.

Organizations determining which controls to acquire from providers verified in the cloud security providers should anchor those decisions to a formal risk assessment aligned to NIST SP 800-30, Guide for Conducting Risk Assessments. More information on navigating provider categories appears in the how to use this cloud security resource section of this site.