Cloud Infrastructure

Why Cloud Security Is Different

In a traditional on-premises environment, the organization owns and is responsible for every layer: the physical hardware, the network, the hypervisor, the operating system, the applications, and the data. Cloud computing changes this by outsourcing some of those layers to a provider — but it does not eliminate the security responsibilities; it divides them. The provider secures what it owns; the customer secures what it controls. The precise dividing line depends on the service model.

This division is called the shared responsibility model. Misunderstanding it — specifically, assuming the cloud provider is responsible for more than it actually is — is one of the most common causes of cloud security failures. The provider publishes a responsibility matrix documenting exactly what they secure and what the customer must secure. Reading that documentation before deployment is not optional; it is the foundation of a secure cloud deployment.

Cloud Service Models — Where the Line Falls

IaaS (Infrastructure as a Service) gives the customer virtual machines, storage, and networking. The provider secures the physical hardware, the data center, and the hypervisor. Everything from the OS upward — patching the operating system, configuring the firewall, securing the applications, protecting the data — is the customer's responsibility. Examples: AWS EC2, Microsoft Azure Virtual Machines, Google Compute Engine.

PaaS (Platform as a Service) gives the customer a managed execution environment. The provider additionally manages the operating system, runtime, and middleware. The customer is responsible for the application code and data deployed on top of the platform. Examples: AWS Elastic Beanstalk, Azure App Service, Google App Engine, Heroku.

SaaS (Software as a Service) delivers a complete application. The provider manages everything through the application layer. The customer is responsible for managing who has access (user accounts, access controls), how the application is configured, and the data they place in it. Examples: Microsoft 365, Salesforce, Google Workspace, Zoom.

Variability in Responsibility Matrices

The responsibility matrix is not identical across all providers or all services. It varies based on the specific cloud provider, the service agreement, and deployment configuration choices. A customer who deploys an RDS managed database instance on AWS has less OS responsibility than a customer running MySQL on an EC2 instance — both are "AWS," but the service model differs. Organizations must review the provider's published responsibility matrix for each specific service they use, not apply a generic assumption about "the cloud provider handles everything below the application."

Cloud Deployment Models

Cloud services can be deployed in four architectural models, each with different security implications:

Hybrid Cloud Security Challenges

A hybrid cloud environment connects an organization's private infrastructure (on-premises or privately hosted) with one or more public cloud providers. This architecture is appealing because it allows organizations to keep sensitive workloads on infrastructure they fully control while leveraging the public cloud's elasticity for variable or less-sensitive workloads. But combining two fundamentally different security environments into one logical system introduces complexity that either environment alone does not have.

1. Inconsistent network protection. The on-premises environment uses physical firewalls with rules configured by the organization's network team. The public cloud environment uses virtual firewalls, security groups, and network access control lists configured through the provider's API or console. These two sets of rules exist in different systems, have different syntax, and may be managed by different teams. A rule that is properly configured on the on-premises firewall may not have a corresponding rule in the cloud security group — creating an unintended path through the cloud-side boundary. Maintaining consistency between the two rule sets requires explicit process, not assumption.

2. Authentication across environments. An on-premises Active Directory handles authentication for internal resources. The cloud provider has its own identity management (AWS IAM, Azure Entra ID, GCP Cloud IAM). If these two identity systems are not federated — connected so that the same credentials work in both — users end up with separate accounts, administrators must manage identity in two places, and the risk of orphaned accounts (active cloud credentials for employees who have left) increases substantially. Identity federation through SAML, OAuth, or OIDC synchronizes the two systems, but the integration itself must be configured and maintained correctly.

3. Diverse monitoring systems. The on-premises SIEM receives logs from on-premises firewalls, servers, and identity systems. The cloud environment generates its own logs in a different format, stored in the provider's proprietary logging service (AWS CloudTrail, Azure Monitor, GCP Cloud Logging). Without deliberate integration, there is no single place where security events from both environments are visible together. An attacker who moves laterally from a compromised on-premises workstation into the cloud environment may be invisible in both SIEMs individually — neither sees the complete picture. Cross-environment log aggregation is a requirement, not an enhancement, for hybrid cloud security.

4. Data transfer risk. When data moves between the private and public cloud environments, it typically traverses public internet infrastructure unless a dedicated private connection is established (AWS Direct Connect, Azure ExpressRoute). Data crossing a public path is at risk of interception. Encryption of all data in transit between environments is mandatory, and the connection itself should be authenticated to prevent man-in-the-middle scenarios.

Third-Party Vendor Risk

The cloud provider itself is a third-party vendor — an external organization on which the customer places significant trust and whose security posture directly affects the customer's security. But the cloud ecosystem extends beyond just the primary provider. Organizations typically also use:

• Managed Service Providers (MSPs) who have administrative access to the cloud environment on the customer's behalf
• Additional SaaS vendors integrated with the primary cloud environment (monitoring tools, CI/CD platforms, identity providers)
• Cloud-based security appliances (WAFs, DLP tools, CASB solutions) that proxy or inspect data flows
• Marketplace applications deployed from the cloud provider's app marketplace, developed by third-party vendors

Each of these relationships is a potential supply chain risk. A compromise of a third-party vendor with privileged access to the customer's cloud environment is functionally equivalent to a direct compromise of that environment. Vendor risk management for cloud environments requires:

Infrastructure as Code (IaC)

In traditional infrastructure management, an administrator logs into a console or connects to a device and makes configuration changes manually. This produces the right configuration — but only on that device, at that moment. The next time a similar device is provisioned, the administrator must repeat the process. Manual steps introduce human error, and over time configurations drift from the intended state as ad-hoc changes accumulate.

Infrastructure as Code defines the desired state of infrastructure — servers, networks, security groups, storage, databases — in text files that are executed by an automation engine to build or modify the actual infrastructure. The code is the source of truth. Common tools include Terraform (multi-cloud), AWS CloudFormation (AWS-native), and Azure Resource Manager (ARM) templates.

Security benefits of IaC:

• Version control: Infrastructure definitions are stored in a version control system (Git). Every change is tracked, attributed to a person, and reversible. Infrastructure changes go through code review just like application code — a second set of eyes can catch a misconfigured security group before it is deployed to production.
• Consistency: The same IaC template deployed to development, staging, and production environments produces identical configurations. A security rule present in staging cannot be missing from production if both are deployed from the same template.
• Configuration drift prevention: When IaC is deployed, it overwrites the current state to match the defined state. A manual change that someone made in the cloud console without going through the IaC process is detected and reverted on the next deployment. The code wins — this enforces that all changes go through the reviewed, version-controlled process.
• Repeatability: Disaster recovery becomes faster and more reliable. Rebuilding an environment from scratch is running the IaC template — not manually reconfiguring hundreds of resources.

Security risks of IaC:

• Secrets in code: Developers sometimes hardcode API keys, passwords, or access tokens directly into IaC templates and commit them to version control. Anyone with access to the repository (or anyone who can read the repository's history after the credential is removed) has the credential. Secrets should be stored in a secrets manager (AWS Secrets Manager, HashiCorp Vault) and referenced by name in the IaC code — never hardcoded.
• Misconfiguration at scale: An error in an IaC template that opens an unintended firewall port or grants excessive IAM permissions is deployed to every environment the template builds. A single misconfiguration in code propagates consistently — which is powerful, but means a security mistake deploys consistently too.
• Compromised IaC repository: If an attacker gains write access to the IaC repository, the next pipeline deployment will apply their changes to the production infrastructure. The repository is a high-value target; it should require MFA, code signing, and pipeline controls that validate changes before deployment.

Serverless Architecture (FaaS)

In serverless computing — more accurately called Function as a Service (FaaS) — developers write individual functions that perform specific tasks. The cloud provider handles everything below the function code: the server, the operating system, the runtime environment, and scaling. The function runs in a stateless container, executes in response to a triggering event, and terminates when done. The developer pays only for the time the function actually runs.

Examples: AWS Lambda, Azure Functions, Google Cloud Functions.

Security model shift: Because the provider manages the OS and runtime, OS patching and infrastructure hardening are off the customer's responsibility list. This is a genuine reduction in the customer's attack surface. The provider ensures the underlying execution environment is current and patched.

However, the customer retains full responsibility for what is still within their control:

Microservices Architecture

A traditional monolithic application is a single codebase that contains all of the application's functionality: user authentication, business logic, data access, reporting. All components run together as one unit. Scaling the application means scaling everything — even the parts that are not under load. A bug in one component can crash the entire application.

Microservices architecture decomposes the application into many small, independent services, each responsible for a specific function. Each service runs independently, can be deployed and scaled independently, and communicates with other services through APIs (Application Programming Interfaces). A failure in one service can be isolated without taking down the entire application.

Security advantages:

• Blast radius containment: A breach in the payment processing microservice does not automatically provide access to the user profile service or the inventory service — each is a separate application with its own access controls.
• Independent security updates: A vulnerable component can be updated and redeployed without requiring a full application release cycle.
• Principle of least privilege applied architecturally: Each service can be granted only the database tables, APIs, and cloud resources it specifically needs — rather than all services sharing one broad credential set.

API security — the critical new requirement:

When all services in a monolith communicate via internal function calls, there is no API to secure. When each microservice communicates with others via network APIs, those APIs are the attack surface. Every API endpoint must be:

• Authenticated: The calling service must prove its identity before the receiving service processes the request — service-to-service authentication using tokens or mutual TLS.
• Authorized: The calling service must have permission to perform the specific operation it is requesting — not all callers can call all endpoints.
• Validated: All input arriving at the API must be validated — a compromised microservice that sends malicious requests to another service should be caught at the receiving API's input validation layer.
• Rate-limited: APIs should enforce request rate limits to prevent abuse (DoS against the API, credential brute force, data scraping).

API gateways (AWS API Gateway, Azure API Management) centralize these controls — authentication, authorization, rate limiting, and logging — at the entry point rather than requiring each microservice to independently implement them.

Connecting the Modern Architecture Concepts