Who is responsible for cloud security? Misconfiguration and the shared responsibility model

Your cloud provider secures the cloud; you secure what you put in it. AWS calls the split "security of the cloud" versus "security in the cloud": data centres, hardware, the hypervisor and the global network belong to the provider, while identities, access permissions, network rules, application code, encryption settings, logs and backups belong to you. Almost no cloud breach happens because the provider's infrastructure failed. They happen because a setting on the customer side was left the wrong way. Gartner's widely quoted forecast made the point bluntly: nearly all cloud security failures would be the customer's fault. So the question worth asking is not "is my provider secure?" but "did I configure my own side correctly?"

Where the line actually falls

The shared responsibility model is not a fixed boundary. It slides depending on the service you buy. Rent a virtual machine (IaaS) and you own the OS patches, the firewall rules and everything you install on top. Use a managed database (PaaS) and the provider patches the engine while you manage permissions and the schema. Even in a pure SaaS product, data classification, user management and sharing settings stay with you.

The most common misreading of this model is assuming cloud servers look after themselves. They do not. An EC2 or Azure VM running an unpatched operating system is exactly as exposed as a physical server in the same state. Your provider's SOC 2 report does not close a six-month-old kernel vulnerability on your instance. Patch management is still your job after the migration.

Mistake one: storage open to the internet

The classic cloud leak has not changed in a decade. An object storage bucket is left publicly readable and its contents can be downloaded with no authentication at all. What makes this dangerous is how quiet it is. No alarm fires, no lock breaks. The files just sit there, and automated internet scanners find them within hours. A 2025 research report found billions of files sitting exposed across hundreds of thousands of misconfigured cloud buckets, including source code, credentials and documents explicitly marked confidential.

Providers have tightened their defaults in response. Amazon announced a change in December 2022 and rolled it out in April 2023, so every newly created S3 bucket now has Block Public Access enabled and ACLs disabled. Microsoft followed by disabling anonymous blob access by default on new storage accounts from August 2023. Read the fine print though: both changes apply only to new resources. A bucket created in 2019 keeps its original settings, and if nobody audits it, it keeps them indefinitely.

Mistake two: identities with far too much power

After storage, the largest category of cloud misconfiguration is identity and access management. The patterns repeat across almost every environment we review: wildcard (*) policies that permit everything, static access keys that have not been rotated in years, MFA switched off on the root or global admin account, an application granted project owner when all it needs is write access to one bucket.

These mistakes share a consequence. They decide the blast radius. When an attacker steals a credential, how far they get is determined entirely by what that credential was allowed to do. The fixes are unglamorous and effective: least privilege, short-lived role-based access instead of permanent keys, and MFA on every administrative account with no exceptions. Applying zero trust to a cloud tenancy is largely this work.

Capital One: how small errors chain together

The 2019 Capital One breach remains the best teaching case, because no single mistake caused it. A misconfigured web application firewall allowed an SSRF attack, the SSRF reached the EC2 instance metadata service, the metadata service handed over temporary IAM credentials, and those credentials carried enough permission to read customer data in S3. Roughly 106 million people were affected. The bank paid an $80 million penalty to the US regulator OCC and settled a class action for $190 million.

The engineering response outlasted the headlines. AWS pushed the token-based second version of the metadata service (IMDSv2) as a defence-in-depth layer against exactly this kind of SSRF abuse, added an account-level setting in March 2024 so all new instance launches default to IMDSv2, and made instance types released from mid-2024 onward IMDSv2-only. The default got safer. Turning the setting on in an older account is still the customer's task.

Mistake three: open management ports and disabled logs

On the network side, two findings dominate: management ports (SSH 22, RDP 3389) opened to 0.0.0.0/0, and databases reachable from the internet without authentication. Both usually start life as "I'll open it temporarily and close it later."

Logging is the quieter failure. If cloud audit trails (AWS CloudTrail, Azure activity logs, GCP audit logs) are switched off, or kept in the same account an attacker just compromised, you cannot answer the only question that matters after an incident: what did they touch, and how much data left? Organisations that struggle to scope a breach notification are usually the ones without usable logs. Shipping audit records to a separate, write-protected account costs very little and is often the only hard evidence you will have.

Backups are on your side of the line

Here is a distinction that catches people out. The provider keeping multiple replicas of your data is durability, not backup. It protects against a failed disk, not against a table someone dropped, a file share encrypted by ransomware or an account takeover. Only your own backup policy covers those. SaaS products work the same way: most have a limited default retention window, and once it passes the data is gone. The 3-2-1 rule still applies in the cloud, but the definition of "off-site" changes. A second bucket in the same region of the same provider does not count.

Configuration drifts, so checks must repeat

Cloud environments move. An engineer adds a temporary console rule to unblock a release. A test environment spins up with a copy of production data. A team opens its own subscription on a corporate card. Six months later there are resources nobody has in an inventory and nobody is monitoring.

Which is why a one-off audit is worth much less than a standing control. Define infrastructure as code (Terraform, Bicep) so changes go through review, use provider guardrails (AWS SCPs, Azure Policy, GCP organization policies) to make rules such as "nobody can create a public bucket" technically impossible to break rather than merely discouraged, and scan for drift on a schedule. Credentials committed into repositories belong to the same problem: cloud configuration is not secure without secrets management.

Measuring where you stand

The reassuring part is that this ground is well mapped. CIS publishes Foundations Benchmarks for AWS, Azure and GCP, updated regularly, and they give you a concrete checklist rather than vague advice. Each provider ships built-in scoring too: AWS Security Hub, the secure score in Microsoft Defender for Cloud, Google Security Command Center. On the open-source side, Prowler and ScoutSuite audit an environment against those benchmarks from outside. The product category as a whole is called CSPM, cloud security posture management.

One caveat about tooling. A scanner returns a list of settings that deviate from a benchmark; it does not tell you which deviations matter. Out of several hundred findings, business risk usually sits in a handful: publicly reachable storage, over-privileged identities, missing audit logs. Prioritisation is still human work.

Compliance does not move with the data

If you operate in Turkey, one legal point deserves emphasis. Storing data with a cloud provider does not stop you being the data controller under KVKK. The provider is typically a data processor, and the obligation to implement technical and organisational measures stays with you. If a misconfiguration leaks personal data, the regulator's counterparty is you, not your provider. Where the servers sit outside Turkey, the rules on cross-border data transfer apply on top of everything above.

A sensible order of work

Start with inventory: which accounts, subscriptions and projects exist, and who owns each one? Then scan for publicly accessible resources and close everything that does not genuinely need to be open. Enforce MFA on administrative accounts and swap long-lived access keys for short-lived roles. Enable audit logging and send it somewhere separate. Test a restore, not just a backup. Once that groundwork is done, take a baseline measurement against the CIS Benchmark and repeat it on a fixed cadence.

At Wedevit we map this picture independently, rank configuration findings by business risk rather than by scanner severity, and build the remediation plan with your engineers. If you also want to see how the environment looks from the outside, a penetration test sits well on top of a configuration review.