Cloud Infrastructure — Glossary

The framework that defines which security responsibilities belong to the cloud provider and which belong to the customer. The dividing line depends on the service model: IaaS (provider secures physical infrastructure through hypervisor; customer secures OS and above), PaaS (provider adds OS and runtime; customer secures applications and data), SaaS (provider secures the application; customer manages data and access). One constant across all models: the customer is always responsible for their own data and for managing who has access to it. The provider publishes a responsibility matrix for each service — customers must read it before deployment. Misunderstanding the boundary is the leading cause of cloud security misconfigurations. "The cloud provider handles security" is never fully correct; the question is always which layers each party handles.

A cloud service model that provides virtualized compute, storage, and networking resources on demand. The provider secures the physical data center, network hardware, and hypervisor. The customer is responsible for: operating system patching and hardening, network security groups and firewall rules, installed applications and their vulnerabilities, and all data stored on the virtual infrastructure. IaaS gives the customer the most control and the most responsibility. Examples: AWS EC2 (virtual machines), AWS S3 (object storage), Azure Virtual Machines, Google Compute Engine. Security implication: a customer who fails to patch the OS on an EC2 instance cannot blame AWS — OS security is explicitly the customer's responsibility in IaaS.

A cloud service model that provides a managed execution environment — the provider handles the operating system, runtime, and middleware in addition to the physical infrastructure. The customer deploys application code and data on top of this managed platform without managing the underlying infrastructure. Customer responsibilities: application code security (input validation, authentication, authorization, business logic), data protection, and access management. Examples: AWS Elastic Beanstalk, Azure App Service, Google App Engine, Heroku. Security implication: a vulnerability in the OS or runtime is the provider's problem to fix; a vulnerability in the application code the customer deployed is the customer's problem to fix. The boundary is the application layer.

A cloud service model that delivers a complete application to end users over the internet. The provider manages every layer: physical infrastructure, OS, runtime, and the application itself. Customer responsibilities are limited to: managing user accounts and access permissions (who can log in and what they can do), configuring the application's security settings, and governing the data they place in the service. Examples: Microsoft 365, Salesforce, Google Workspace, Zoom, Dropbox. Security implication: the provider controls application security — a breach in the SaaS application itself is the provider's incident, not the customer's. However, if the customer's admin account is compromised and an attacker uses it to export all data, that is the customer's responsibility (access management failure).

A cloud deployment model that combines private infrastructure (on-premises data center or private cloud) with one or more public cloud environments, connected to function as a unified system. Organizations typically place sensitive or regulated workloads on the private side and variable, less-sensitive workloads on the public side. Security challenges unique to hybrid environments: (1) inconsistent firewall and security group rules between environments; (2) identity management across two different IAM systems requiring federation; (3) disparate logging systems requiring integration for complete visibility; (4) data transfer between environments traversing public internet unless dedicated connections (AWS Direct Connect, Azure ExpressRoute) are established. Hybrid cloud is operationally complex — the security policy that applies to each environment must be explicitly aligned, not assumed to be consistent.

The practice of defining and managing cloud infrastructure — servers, networks, security groups, storage, databases — as text files (code) executed by an automation engine, rather than through manual console configurations. Tools: Terraform (multi-cloud), AWS CloudFormation (AWS-native), Azure Resource Manager (ARM) templates. Security benefits: version control of all infrastructure changes; peer review of infrastructure definitions before deployment; consistent configuration across environments; configuration drift prevention (the code overwrites manual changes on each deployment). Security risks: secrets hardcoded in templates; misconfigurations that deploy at scale; compromised IaC repository granting infrastructure control to an attacker. IaC templates should be scanned for security issues (open-source tools: Checkov, tfsec) before deployment, just as application code is scanned for vulnerabilities.

A cloud execution model in which the provider manages all infrastructure (servers, OS, runtime, scaling) and the customer deploys individual functions that execute in response to triggering events. Functions run in stateless containers, typically short-lived, with no persistent server to manage or patch. Examples: AWS Lambda, Azure Functions, Google Cloud Functions. Provider responsibility: OS patching, runtime security, scaling, infrastructure availability. Customer responsibility: function code security (no injection vulnerabilities), IAM permissions applied to the function (least privilege — function should only have permissions it needs), input validation (all event payloads must be validated), secrets management (no hardcoded credentials), and dependency security (third-party libraries imported by the function). The provider managing the OS does not mean the customer has no security responsibilities — it means the customer's security responsibility shifts entirely to the application layer.

The gradual divergence of an infrastructure component's actual configuration from its intended, documented, or approved state, caused by manual ad-hoc changes that are not tracked or enforced through a formal process. In cloud environments, configuration drift occurs when administrators make direct changes in the cloud console, CLI, or API without updating the IaC templates that define the intended state. Over time, the actual environment no longer matches the approved design — security controls may be weakened, firewall ports may be open, and IAM permissions may have been broadened for "temporary" troubleshooting that was never reversed. IaC is the primary defense against configuration drift: every deployment enforces the defined state, overwriting manual deviations. Drift detection tools (AWS Config, Azure Policy) continuously compare actual resource configuration against the defined standard and alert on deviations.

An application architecture that decomposes a monolithic application into many small, independent services each responsible for a specific function, deployable and scalable independently, communicating via APIs. Contrast with monolith: a single codebase where all components run together — scaling one component requires scaling everything; a bug in one area can crash the whole application; a security breach potentially exposes all functionality. Microservices security advantages: blast radius containment (a compromised payment service does not automatically compromise the user service), independent patching, and per-service least-privilege IAM assignments. Key security challenge introduced: every service-to-service communication is now an API call that must be authenticated, authorized, and validated — securing inter-service APIs is a new attack surface that did not exist in the monolith.

Security controls applied to the interfaces through which software components communicate — critical in microservices architectures where all inter-service communication occurs via APIs. Four required controls: Authentication (the caller must prove identity before the API processes the request — service tokens, API keys, mutual TLS); Authorization (the caller must have permission for the specific operation — not all authenticated callers can call all endpoints); Input validation (all data arriving at the API must be validated — malicious payloads can cause injection, SSRF, and other vulnerabilities); Rate limiting (caps on request volume prevent DoS, brute force, and data scraping). API gateways (AWS API Gateway, Azure API Management) centralize these controls at the entry point. An unauthenticated API endpoint in a microservices environment allows any caller — including compromised internal services — to invoke its functionality without restriction.

The security risk introduced by external vendors with access to an organization's cloud environment — extending beyond the primary cloud provider to include MSPs with admin access, SaaS tools integrated with the cloud environment, security appliances deployed in the cloud, and marketplace applications. Each vendor is a potential supply chain attack vector: a compromise of the MSP's credentials or the SaaS vendor's platform may grant an attacker access to the customer's cloud environment. Risk management requires: initial vendor security assessment (SOC 2 Type II, ISO 27001, penetration test results); contractual controls (breach notification timelines, right to audit, data deletion on termination); continuous monitoring (changes in vendor certifications, announced incidents); and incident response integration (vendor escalation contacts in the IR plan). MSPs with global admin access represent the highest-impact third-party risk.

A mechanism that connects two separate identity management systems so that a user authenticated by one system is recognized by the other without a separate login. In hybrid cloud environments, federation links the on-premises identity provider (Active Directory) with the cloud identity provider (Azure Entra ID, AWS IAM Identity Center) using standards such as SAML 2.0, OAuth 2.0, or OpenID Connect (OIDC). Security benefits: users have a single set of credentials managed centrally (a password change or account disable in AD applies immediately in the cloud), eliminating orphaned cloud accounts for departed employees; centralized MFA enforcement applies across both environments; centralized audit logging captures authentication events from both. Without federation, cloud accounts become a separate, less-managed identity store with separate credentials that may not be disabled when employees leave.