Cloud security is the practice of protecting data and workloads that run on infrastructure somebody else operates. The provider secures the platform; the customer secures what they deploy on it. Spreading workloads across several providers keeps that division intact and multiplies the number of places it has to be enforced consistently.
Quick Overview
What you’ll learn:
- Why perimeter thinking stopped describing a cloud estate, and what replaced it
- How responsibility is actually divided between provider and customer
- The threat categories that recur across cloud environments regardless of provider
- Which pillars a workable cloud security strategy rests on
- What running several providers adds to the work, beyond more of the same
- Where competence has to be built for any of this to hold
Who this article is for:
- IT and security managers taking responsibility for a cloud estate
- Architects designing across more than one provider
- Learning and development leads planning security competence in technical teams
Reading time: 7 minutes
The Perimeter Is Gone, and With It the Old Division of Labour
Traditional IT security was built around a boundary. Assets sat inside a network you owned, defences sat at its edge, and the security question was largely one of who was allowed through. A cloud estate dissolves that boundary: resources are distributed, access happens over the public internet, and the assets themselves are created and destroyed faster than any inventory maintained by hand.
What replaces the boundary is a division of duties that has to be read carefully. The AWS Shared Responsibility Model states it plainly — the provider is accountable for the security of the cloud, meaning the physical infrastructure, the backbone network and the virtualisation layer, while the customer is accountable for security in the cloud: service configuration, operating systems, applications, identity and the data itself. Microsoft’s documentation on shared responsibility in the cloud draws the same line and adds a detail worth internalising — the split moves depending on the service model, so the customer’s share is larger for infrastructure services than for software delivered as a service.
The practical consequence is that most cloud incidents are not provider failures. They happen on the customer’s side of the line, in configuration and access management, which is precisely the side that traditional perimeter tooling was never designed to watch. For a broader treatment of protecting workloads across deployment models, see our guide to securing data and applications in cloud computing environments.
Threat Categories That Recur in Cloud Estates
The specific exploits change; the categories do not.
Misconfiguration remains the most frequently observed source of incidents — storage exposed publicly, databases reachable without authentication, firewall rules written permissively during a deployment and never tightened afterwards.
Credential compromise follows: weak or leaked passwords and API keys used to reach a cloud account directly, often obtained by phishing an administrator rather than by breaking anything technical.
Unsecured interfaces matter more in the cloud than elsewhere, because services talk to each other through APIs by default. An interface that is exposed, under-authenticated or over-permissive is a route into everything behind it.
Data exposure is the outcome rather than a technique — confidential material lost through misconfiguration, intrusion, stolen credentials or someone inside acting outside their remit.
Application-layer attacks target what the customer deployed: injection, cross-site scripting and the rest of the familiar catalogue, unchanged by the hosting model.
Persistent targeted intrusion describes the patient, well-resourced adversary who establishes a foothold and stays. Detection, not prevention alone, is what addresses this class.
Shared-tenancy risk covers isolation between customers on common physical infrastructure. Providers invest heavily here and the practical exposure is small, but it belongs on the register rather than being assumed away.
Management sprawl across providers is the category that grows with the estate: policies, permissions and monitoring that drift apart because each platform expresses them differently.
Pillars of a Workable Cloud Security Strategy
Identity and access management carries the most weight, because in a cloud estate identity has become the control plane. Strong authentication, least privilege and regular review of what accounts and services may actually do are the baseline. NIST’s Zero Trust Architecture publication sets out seven tenets for organisations moving away from implicit trust based on network location — worth reading before designing an access model, because it names assumptions that are otherwise inherited unexamined.
Data protection means encryption at rest and in transit, classification so that effort follows sensitivity, deliberate management of encryption keys, and controls against exfiltration.
Infrastructure and network security covers firewall and security-group configuration, segmentation into virtual networks and subnets, protection against volumetric attacks, and routine vulnerability scanning.
Application security puts the effort into the build: secure coding practices, scanning of code and dependencies, protection of interfaces, and a web application firewall where public exposure justifies one.
Monitoring, detection and response turns the rest into something observable. Continuous collection of security events, alerting that someone actually receives, and an incident response plan that has been rehearsed rather than filed.
Configuration management and compliance closes the loop with infrastructure as code and automated policy checks. Regulation sets hard deadlines here: the General Data Protection Regulation requires a personal-data breach to be reported to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it — an obligation an estate cannot meet if it does not know what it holds and where. Teams formalising this work will find the ground covered in the Security in the cloud course.
What Multi-Cloud Adds
Running several providers is rarely a security decision, but it is always a security consequence.
Tooling and interfaces are inconsistent: each platform has its own security console, its own vocabulary and its own defaults, which makes a single, comparable picture of the estate hard to assemble. Identity has to be managed in several systems at once, and permissions that look equivalent across two providers frequently are not. Data moving between environments needs protection in transit across links that neither provider fully owns. Monitoring has to be aggregated somewhere before an incident spanning providers can even be recognised as one incident. And the competence requirement multiplies, because platform knowledge transfers only partially.
Organisations that take this on generally invest in posture management and workload protection tooling that spans providers, and — more importantly — in the team that operates it. Choosing the deployment model deliberately helps; our comparison of multi-cloud and hybrid cloud strategy sets out what each model asks of an organisation before it is committed to.
Building the Competence Inside the Team
Cloud security is a competence problem wearing a technical costume, and it can be planned like one. Foundations first — the shared responsibility split, the recurring threat categories, the basic controls — for everyone in IT rather than only the security function. Then platform-specific depth and certification for the people directly accountable for a given provider. Then secure coding and DevSecOps practice for development teams, so that protection is built in rather than added at review. Practical workshops on the tooling that the organisation actually runs, incident exercises that rehearse the response plan under time pressure, and awareness campaigns for everyone else complete the picture.
The reason to plan this rather than let it accumulate is that the failure modes described above are overwhelmingly human: a permission granted broadly because it was quicker, a bucket opened for a migration and left open, an alert nobody owned. Tooling narrows those gaps; it does not close them.
Build Your Skills
Cloud security is not optional, and in a multi-cloud estate it is not something a single specialist can hold alone. The Lead Cloud Security Manager programme works through governance, risk and the management of cloud security across providers, for the people who have to answer for it. Check the programme and sign up to build your skills with EITT’s experts.
Frequently Asked Questions (FAQ)
How does shared responsibility differ from traditional IT security?
In a traditional estate the organisation controls the whole stack and answers for all of it. In the cloud the provider secures the infrastructure and the customer secures configuration, access and data. The division is not fixed either — it shifts with the service model, so an organisation using both infrastructure and software services is working with different boundaries at the same time.
What is the largest risk in a multi-cloud strategy?
Inconsistency. Different tooling and vocabularies across providers make it easy for policies to drift apart, and identity has to be managed in several places at once, which is where misconfiguration enters. Posture management tooling that gives one view across environments is the usual answer, but it is a way of seeing the problem rather than a substitute for a decided policy.
Where should a cloud security strategy start?
With an accurate reading of the shared responsibility split for every service actually in use, followed by identity: multi-factor authentication and least privilege before anything else. Training runs alongside rather than afterwards, because human error and misconfiguration account for a large share of incidents and neither is fixed by adding a product.
Are cloud security certifications worth it for a technical team?
For people directly accountable for a platform, yes — provider certifications confirm practical knowledge of tooling that differs meaningfully between clouds. In a multi-cloud organisation, having certified people across more than one platform shortens the response to incidents that span providers and reduces the configuration mistakes that come from applying one platform’s habits to another.
Is the public cloud safe for sensitive data?
It can be, given deliberate configuration: encryption, tightly scoped access, logging and compliance with the regulation that applies to the data in question. The providers offer controls that most organisations could not build themselves. What the cloud does not do is apply them on your behalf, which is the point of the responsibility split.