Cloud Security 101: Architecture: Someone Else’s Computer (That’s Technically Your Problem)

By Tech Corsair

There is a sticker that has been doing the rounds at security conferences for the better part of a decade now. It reads: "There is no cloud. It's just someone else's computer." It was funny the first time. It was mildly amusing the fiftieth. By the three-hundredth sighting, it had achieved a sort of zen-like truth status -- the security equivalent of "the house always wins."

Because here is the thing: the sticker is technically correct (the best kind of correct), but it dramatically undersells the problem. Yes, the cloud is someone else's data centre. But the security responsibility? That stayed right where it was -- squarely on your desk, nestled between the half-eaten sandwich and the stack of unread compliance reports.

Welcome to Cloud Security 101. Grab a cuppa. This is going to be a bumpy ride through shared responsibility models, identity misconfigurations, and the enduring mystery of why people keep leaving S3 buckets open to the entire internet.

The Shared Responsibility Model: A Polite Way of Saying 'Not Our Problem'

Every major cloud provider operates under what they cheerfully call the Shared Responsibility Model. In practice, this is an elegantly worded document that explains precisely which security failures are their fault and which are yours. Spoiler: most of them are yours.

The model shifts depending on the service type, and understanding where the boundary lies is the single most important concept in cloud security. Get this wrong, and everything downstream is built on sand.

IaaS: Infrastructure as a Service

Think EC2 instances, Azure Virtual Machines, GCP Compute Engine. The provider handles:

• Physical security (the data centre, the locks, the guards, the very serious fences)
• Hardware (servers, storage, networking kit)
• Hypervisor (virtualisation layer)

Everything above the hypervisor is your problem:

• Operating system patching
• Network configuration and firewalls
• Application security
• Data encryption
• Identity and access management
• Basically everything that matters

IaaS gives the most control and the most rope with which to hang oneself. It is the "here are the keys to a Formula 1 car, good luck with the corners" of cloud computing.

PaaS: Platform as a Service

Services like AWS Elastic Beanstalk, Azure App Service, and Google App Engine. The provider takes on more responsibility:

• OS patching and maintenance
• Runtime environment
• Middleware

The customer still owns:

• Application code and its vulnerabilities
• Data classification and protection
• User access and authentication
• Application-level encryption

PaaS is the middle ground. Fewer things to break, but the things that remain breakable tend to be the ones that make headlines.

SaaS: Software as a Service

Microsoft 365, Salesforce, Google Workspace. The provider handles nearly everything infrastructure-related. The customer is responsible for:

• Data -- what goes in and who can see it
• User management -- who has accounts and what they can do
• Configuration -- those 400 settings nobody ever reviews
• Integration security -- OAuth tokens, API connections, third-party apps with suspiciously broad permissions

SaaS is where organisations convince themselves they have outsourced security entirely. They have not. They have outsourced infrastructure security and kept the bits that actually cause breaches: misconfiguration and identity management.

The Uncomfortable Summary

Notice how "Customer" appears in every single column for identity, data, and configuration? That is not a coincidence. That is the shared responsibility model quietly telling everyone where the breaches will come from.

The Cloud-Native Attack Surface: New Infrastructure, Same Old Mistakes

Moving to the cloud did not eliminate the attack surface. It transformed it. The old perimeter dissolved, and in its place emerged a sprawling landscape of APIs, identity systems, and configuration settings -- each one a potential entry point for anyone paying attention.

IAM Misconfiguration: The Gift That Keeps on Giving

Identity and Access Management (IAM) misconfiguration is the number one cause of cloud security incidents, and it is not even close. The problem is structural: cloud IAM systems are extraordinarily powerful and extraordinarily complex.

Common sins include:

• Overpermissive policies -- granting : (all actions on all resources) because "it works and we'll tighten it later." (They will not tighten it later.)
• Long-lived access keys -- static credentials that sit in environment variables, config files, and occasionally committed to public GitHub repositories
• No MFA on privileged accounts -- because apparently the root account password CloudAdmin2024! is considered sufficient
• Excessive cross-account trust -- when every account trusts every other account, trust becomes meaningless

A typical overpermissive IAM policy in AWS looks something like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

This policy grants the holder the ability to do literally anything in the AWS account. It is the cloud equivalent of handing someone the master key to the building, the alarm code, and a note saying "help yourself." And yet it appears in production environments with alarming regularity.

Public Storage: The S3 Bucket Problem

Public cloud storage misconfiguration has its own sub-genre of breach reporting at this point. AWS S3 buckets, Azure Blob Storage containers, and GCP Cloud Storage buckets have all featured prominently in data exposures affecting millions of records.

The pattern is almost always the same:

1. Developer creates a storage bucket
2. Developer needs something to work quickly
3. Developer sets access to public
4. Developer forgets about it
5. Researcher (or attacker) finds it
6. Organisation appears in headlines

AWS has added increasingly aggressive warnings, default encryption, and the "Block Public Access" setting at the account level. And still people manage to expose data. It is a testament to human ingenuity in the face of safety guardrails.

Exposed APIs and Metadata Services

Cloud environments run on APIs. Every action -- launching an instance, modifying a security group, reading a secret -- is an API call. This means:

• Exposed management APIs become direct control-plane attack vectors
• Unauthenticated or poorly authenticated APIs are trivially exploitable
• Instance metadata services (IMDS) can leak credentials to any process running on the instance

The metadata service attack is particularly elegant in its simplicity. On AWS, any process on an EC2 instance can query:

http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>

This returns temporary IAM credentials. If an attacker achieves code execution on the instance -- say, via an SSRF vulnerability in a web application -- they can harvest these credentials and use them from anywhere. The Capital One breach of 2019 used exactly this technique.

AWS introduced IMDSv2 (requiring session tokens for metadata queries) to mitigate this, but IMDSv1 remains enabled by default in many environments because backwards compatibility is the security world's recurring villain.

---

Cloud Identity and Access Management: Getting It Right (Or At Least Less Wrong)

If the shared responsibility model teaches one lesson, it is this: identity is the new perimeter. In a world without network boundaries, who you are and what you are allowed to do is the primary security control.

Principles That Actually Matter

Least privilege -- Grant the minimum permissions required for a task. Not "minimum permissions that still let the developer work without complaining," but actual minimum permissions. Yes, this is harder. No, that is not an excuse.

Separation of duties -- The person who writes the deployment pipeline should not be the person who approves production releases. The account that reads audit logs should not be the account that can delete them.

Just-in-time access -- Rather than standing permissions, grant elevated access only when needed and revoke it automatically. Tools like AWS IAM Access Analyzer, Azure PIM (Privileged Identity Management), and GCP's IAM Recommender help identify and reduce over-provisioned access.

Federation over local accounts -- Centralise identity through an identity provider (IdP) rather than creating local cloud accounts. SAML 2.0 and OIDC federation mean one identity source, one MFA policy, one place to disable a leaver's access.

Service accounts need love too -- Non-human identities (service accounts, machine identities, workload identities) frequently have broader permissions than any human user and are subject to far less scrutiny. They should have the same governance: rotation, least privilege, monitoring, and lifecycle management.

The Role Explosion Problem

In any sufficiently complex cloud environment, the number of IAM roles and policies grows exponentially. What starts as a tidy set of roles becomes an impenetrable thicket of custom policies, inline permissions, trust relationships, and permission boundaries that no single person fully understands.

This is not a failure of discipline. It is an emergent property of complex systems. The mitigation is tooling: automated policy analysis, unused permission detection, and regular access reviews. Manual IAM governance at scale is a polite fiction.

---

The Big Three: Security Models Compared

The three major cloud providers -- AWS, Azure, and GCP -- share the same fundamental security model but differ in implementation, tooling, and naming conventions. Because apparently the cloud industry looked at the security landscape and thought, "What this really needs is three slightly different names for the same concept."

AWS (Amazon Web Services)

AWS security is built around IAM policies (JSON documents defining permissions), Security Groups (instance-level firewalls), and VPCs (Virtual Private Clouds for network isolation).

Key security services:

• CloudTrail -- API call logging (the audit log of everything)
• GuardDuty -- threat detection using ML and threat intelligence
• Security Hub -- centralised security findings aggregation
• Config -- resource configuration tracking and compliance
• KMS -- key management for encryption

AWS follows an "opt-in" security philosophy for many features. Things are not necessarily secure by default; they require deliberate configuration. This provides flexibility at the cost of requiring competence -- a trade-off that has generated quite a lot of breach reports.

Azure (Microsoft)

Azure security leans heavily on Azure Active Directory (Entra ID) for identity, Network Security Groups for traffic filtering, and Azure Policy for governance.

Key security services:

• Microsoft Defender for Cloud -- posture management and threat protection
• Sentinel -- cloud-native SIEM
• Key Vault -- secrets and key management
• Monitor and Log Analytics -- centralised logging
• Entra ID Conditional Access -- context-aware access control

Azure's strength is its integration with the Microsoft ecosystem. If an organisation already runs Active Directory, Microsoft 365, and Intune, the security tooling fits together relatively seamlessly. The weakness is the same: the assumption of a Microsoft-centric world does not always hold.

GCP (Google Cloud Platform)

GCP security centres on IAM with resource hierarchy (Organisation > Folders > Projects), VPC Service Controls for API-level perimeters, and BeyondCorp principles for zero-trust access.

Key security services:

• Security Command Center -- asset discovery and threat detection
• Chronicle -- security analytics (essentially Google-scale SIEM)
• Cloud Audit Logs -- admin and data access logging
• Cloud KMS -- encryption key management
• Binary Authorization -- deploy-time security controls for containers

GCP tends to be more opinionated about security defaults -- many features are secure by default, and the resource hierarchy enforces policy inheritance. This reduces misconfiguration at the cost of flexibility. For most organisations, that is a favourable trade.

Multi-Cloud: The Complexity Multiplier

An increasing number of organisations operate across multiple cloud providers, which means maintaining expertise in all of the above simultaneously. Multi-cloud security requires abstraction layers, consistent policy frameworks, and tooling that works across providers.

This is where cloud security posture management (CSPM) tools earn their keep -- Prisma Cloud, Wiz, Orca, Lacework, and others provide cross-cloud visibility. Without them, multi-cloud security is less a strategy and more an aspiration.

---

Practical Starting Points

For those staring at a cloud environment and wondering where to begin, the following list is neither exhaustive nor revolutionary, but it covers the issues that cause the most real-world damage:

1. Enable cloud audit logging everywhere -- CloudTrail in AWS, Activity Log in Azure, Audit Logs in GCP. If it is not logged, it did not happen (as far as the incident response team is concerned)
2. Enforce MFA on all human accounts -- especially privileged ones. This single control prevents a staggering percentage of account compromise
3. Block public access to storage by default -- enable account-level public access blocks and only create exceptions with documented justification
4. Review IAM permissions quarterly -- use provider-native tools to identify unused permissions and overprivileged accounts
5. Enable cloud security posture management -- even the free tiers of provider-native tools (Security Hub, Defender for Cloud, Security Command Center) catch common misconfigurations
6. Implement network segmentation -- VPCs, subnets, security groups. Not everything needs to talk to everything else
7. Encrypt data at rest and in transit -- most providers make this easy. There is no excuse for unencrypted data in 2026

---

The Bottom Line

Cloud security is not a destination. It is not a product one can purchase, a certification one can achieve, or a project with a completion date. It is an ongoing discipline of understanding what has been deployed, who has access to it, and what could go wrong.

The cloud did not make security harder, exactly. It made it different. The threats moved from "someone breaking through the firewall" to "someone guessing the password to the admin console" or "someone leaving a storage bucket open to the world." The fundamentals -- least privilege, defence in depth, monitoring, incident response -- remain unchanged. Only the implementation details shifted.

And those implementation details? They shift again every time the provider releases a new service, which in AWS's case is roughly every fifteen minutes.

So yes, the cloud is just someone else's computer. But the data on it is still yours, the configuration is still yours, and the breach notification letter? That will have your organisation's name on it, not Amazon's.

Best get it right, then.

---

Next in the series: Cloud Security 102 covers AWS forensics -- specifically, what to do when someone leaves the S3 bucket open and the horse has already bolted.

Tech Corsair -- techcorsair.co.uk