Cloud Infrastructure Flashcards

The framework dividing security responsibilities between the cloud provider and the customer, with the split determined by service model. IaaS: provider secures physical infrastructure through hypervisor; customer secures OS, applications, data. PaaS: provider additionally secures OS and runtime; customer secures application code and data. SaaS: provider secures the application; customer manages data and access. The constant across all models: data governance and access management are always the customer's responsibility — the provider never assumes control over who the customer grants access or what data they store. Misunderstanding this boundary is the leading cause of cloud security failures.

OS patching is the clearest differentiator between IaaS and PaaS. IaaS: the customer manages virtual machines — OS patching is entirely the customer's responsibility. If an EC2 instance is running an unpatched OS and is exploited, that is the customer's fault, not AWS's. PaaS: the provider manages the OS and runtime — a vulnerability in the underlying platform is the provider's responsibility to patch. The customer only manages their deployed application code. SaaS: the provider manages everything including OS, runtime, and application — customers have no OS-level responsibility. Exam rule: "who is responsible for OS patching?" → IaaS = customer; PaaS/SaaS = provider.

Four security challenges specific to hybrid cloud environments that do not exist in purely on-premises or purely public cloud: (1) Inconsistent network protection: on-prem uses physical firewalls; cloud uses security groups — different systems requiring explicit alignment. (2) Authentication management: separate AD and cloud IAM systems require identity federation (SAML/OIDC) to prevent orphaned cloud accounts. (3) Diverse monitoring: on-prem SIEM and cloud provider logs must be integrated for complete cross-environment visibility. (4) Data transfer risk: data crossing between environments may traverse public internet — dedicated connections (Direct Connect/ExpressRoute) and transit encryption are required. The root challenge: two security environments with different models must function as one.

Defining cloud infrastructure (servers, networks, security groups, storage) as text files executed by an automation engine rather than through manual console configuration. Tools: Terraform, AWS CloudFormation, Azure ARM templates. Security benefits: every change tracked in version control; infrastructure reviewed like code before deployment; consistent configurations across all environments; configuration drift prevention (code overwrites manual changes on each deployment). Security risks: secrets hardcoded in templates; misconfigurations that deploy consistently at scale; a compromised IaC repository grants the attacker infrastructure control. Templates should be scanned by security tools (Checkov, tfsec) before deployment. Drift detection tools (AWS Config, Azure Policy) alert when actual infrastructure diverges from the IaC-defined state.

The divergence between an infrastructure component's actual configuration and its intended, approved state — caused by manual changes that bypass the formal change management process. In cloud environments, drift occurs when administrators directly modify resources in the console or CLI without updating the IaC templates. Over time, security controls may be weakened, ports opened, and IAM permissions broadened without review. IaC prevents drift: the next deployment overwrites the actual state to match the code. Drift detection tools continuously compare actual resource configurations against the defined standard and alert on deviations. The key insight: a security misconfiguration introduced by a manual change at 11PM during an incident may remain for months if there is no drift detection — the code review process that would have caught it was bypassed.

In serverless (FaaS — Function as a Service), the provider manages OS, runtime, infrastructure, and scaling. The customer deploys function code only. Provider's responsibility: OS patching, runtime security, hardware, scaling. Customer's responsibility: function code security (no injection vulnerabilities), IAM permissions on the function (least privilege — function should only have the specific permissions it requires), input validation (all event trigger payloads must be validated to prevent event injection), secrets management (no hardcoded credentials in code), and third-party library security. Key risk: an over-privileged function that is compromised grants the attacker the function's permissions — which may include full AWS account access if AdministratorAccess was lazily assigned. Examples: AWS Lambda, Azure Functions, Google Cloud Functions.

A monolith is a single codebase containing all application functionality — all components run together, share one credential set, and a breach in any area potentially exposes everything. A microservices architecture decomposes the application into many small, independent services each responsible for a specific function, communicating via APIs. Security advantages of microservices: blast radius isolation (a compromised service doesn't automatically expose all others), independent patching, per-service least-privilege IAM. Key new challenge: all inter-service communication is now via network APIs — every API call must be authenticated, authorized, and have its input validated. In a monolith, components call each other as internal functions with no network attack surface. In microservices, every service-to-service call is a potential attack vector.

APIs are the communication layer between microservices and the entry point for external access. Four required security controls: Authentication: the caller proves identity before the API responds — service tokens, mutual TLS, or API keys; "internal network = trusted" is not authentication. Authorization: the authenticated caller must have permission for the specific operation — not all callers can call all endpoints. Input validation: all data arriving at the API must be validated — malicious payloads cause injection, SSRF, and other vulnerabilities. Rate limiting: caps on request volume prevent DoS, brute force, and data scraping. API gateways centralize these controls. An unauthenticated internal API allows any service in the cluster — including a compromised one — to call its endpoints freely.

Cloud ecosystems extend beyond the primary provider to include MSPs with admin access, integrated SaaS tools, cloud security appliances, and marketplace applications — each a potential supply chain attack vector. Vendor risk management lifecycle: Pre-contract: SOC 2 Type II, ISO 27001 review; Contract: breach notification timeline (must meet regulatory minimums), right-to-audit, data deletion on termination; Ongoing: monitor for vendor security announcements, track certification renewals, SIEM alerts on anomalous vendor activity; Incident: vendor escalation contacts in IR plan, defined responsibility split. Highest risk: MSPs with global admin access — a compromised MSP credential grants the attacker administrative access to every customer account the MSP manages simultaneously. MSP access should be scoped to minimum required and time-limited.

Four deployment models with different security profiles: Public cloud: shared multi-tenant infrastructure managed by the provider (AWS/Azure/GCP) — broadest scalability, lowest cost, multi-tenancy isolation enforced by provider. Private cloud: dedicated to one organization, on-premises or hosted — maximum control, higher cost, no multi-tenancy concerns. Community cloud: shared among organizations with common requirements (government agencies, healthcare orgs) — shared governance and compliance framework, member organizations have a shared trust relationship. Hybrid cloud: combination of private + public — sensitive/regulated workloads on private, elastic workloads on public; most operationally complex; requires secure interconnection (Direct Connect/ExpressRoute), identity federation, and consistent security policy across both environments.