This article is based on a two-part series originally published on Forbes.com. Part 1 covered the shared responsibility model and zero-trust fundamentals. Part 2, summarised and expanded here, focuses on common cloud threats and practical mitigation recommendations.
The Customer Is Still the Weakest Link
To date, the majority of well-documented cloud security incidents have been caused by customer-side failures rather than breaches of the cloud service provider’s (CSP’s) own infrastructure. This is an important distinction. CSPs typically have far greater visibility into network configuration and data flows than their customers do — yet they often shield that infrastructure behind proprietary tooling and interfaces, creating a meaningful information asymmetry.
Customers can begin to close this gap by adopting a shared security model with their CSP and by layering in their own zero-trust controls. Before defining solutions, however, it is worth cataloguing the threats that multicloud teams most commonly face.
Common Threats to Cloud Security
1. Misconfiguration and Insufficient Security Settings
Misconfiguration is consistently cited as one of the leading root causes of cloud breaches across both government agencies and commercial organisations. In practice, misconfiguration most often means incorrect Identity and Access Management (IAM) role assignments — giving cloud service accounts more privilege than they need, or failing to restrict access at all.
The canonical example is improperly configured AWS S3 buckets left publicly readable. AWS has since introduced default-block settings and improved its console warnings to help customers avoid this mistake, but misconfigured object storage remains a widespread problem across all major cloud platforms.
2. Insecure APIs
APIs are the primary interface through which customers manage and export cloud data. When APIs are poorly designed, inadequately authenticated, or sourced from third-party vendors with weak security postures, they become high-value targets. Attackers who discover an exposed or weakly authenticated API endpoint can potentially enumerate resources, exfiltrate data, or pivot deeper into a cloud environment without triggering conventional perimeter alerts.
3. Insider Threats — Intentional and Unintentional
Insider threats sit on a wide spectrum. At one end are untrained or negligent employees who hold cloud accounts without appropriate controls — a misconfigured resource or an accidentally shared credential can cascade into a significant incident. At the other end are malicious actors, either employees or external attackers who have obtained insider-level access.
The Capital One breach (2019) is frequently referenced as a case where an attacker exploited a misconfigured Web Application Firewall to assume a cloud IAM role and access sensitive data stored in S3 — illustrating how an outsider can effectively operate as a privileged insider once a foothold is established.
4. Network Misconfiguration
The elasticity of cloud infrastructure — spinning up servers and network segments in minutes — creates significant risk when the people performing those actions do not fully understand the underlying network model. Specific examples include:
- Servers exposed without SSH key authentication or with default/weak credentials
- Unnecessarily open inbound ports creating attack surfaces for DDoS and brute-force campaigns
- Overly permissive rules on cloud-native Security Groups
- Misconfigured Network Access Control Lists (NACLs) that fail to restrict lateral movement
Because cloud environments democratise infrastructure provisioning, it is unsafe to assume that every team member who can click “Launch” also understands the network security implications of what they are deploying.
Four Mitigation Strategies for Multicloud Security
No single control eliminates multicloud risk. The following four strategies, used in combination, can meaningfully reduce an organisation’s attack surface and improve its overall security posture.
1. Zero-Trust Security
Zero trust operates on the principle of “never trust, always verify.” In a multicloud context this is especially relevant: workloads span environments that fall entirely outside the traditional corporate perimeter, making perimeter-based security controls ineffective by design.
Key zero-trust techniques applicable to cloud include:
- Microsegmentation: Dividing cloud workloads into small, independently controlled network segments so that a breach of one workload cannot automatically reach others.
- Identity-aware proxies: Authenticating and authorising every request based on user and device identity rather than network location.
- Single access gateways: Centralising ingress and egress inspection, analogous to the US government’s Trusted Internet Connection (TIC) architecture.
- Mandatory verification of every access request: No implicit trust based on IP address, VPN membership, or previous authentication.
When implemented consistently, zero trust reduces the blast radius of any single compromise and provides greater visibility into who is accessing what across your cloud estate.
2. Cloud Access Security Brokers (CASBs)
A CASB sits between users and cloud services, enforcing security policies — visibility, compliance, data security, and threat protection — across sanctioned and unsanctioned SaaS, IaaS, and PaaS usage. CASBs are particularly useful for discovering shadow IT and enforcing consistent data-loss prevention (DLP) policies across multiple cloud vendors.
Adoption of CASBs has historically been slower than analysts anticipated. According to Gartner’s Hype Cycle reporting referenced in the original Forbes article, CASBs were entering the “trough of disillusionment” at the time of writing (circa 2019–2020). Several independent CASB vendors have since been acquired and folded into broader security platforms. Microsoft, for example, has integrated CASB capabilities directly into Microsoft Defender for Cloud Apps (formerly Microsoft Cloud App Security).
When evaluating a CASB, consider whether it provides native integrations with each cloud platform in your estate, and whether it will be maintained as a discrete product or absorbed into a larger suite.
3. Workforce Training Tailored to Multicloud Environments
Cloud migration plans frequently budget for tooling and architecture but under-invest in people. Teams trained exclusively on one CSP’s console and security model can introduce risk when the organisation adds a second or third cloud platform, because security assumptions from AWS do not map directly onto Azure or Google Cloud — and vice versa.
Effective multicloud security training should cover:
- The shared responsibility model as it applies to each CSP in use
- IAM fundamentals and least-privilege principles specific to each platform
- Safe storage and API configuration practices across vendors
- Incident recognition and escalation procedures for cloud-native environments
Training should be treated as a continuous programme, not a one-time onboarding exercise, given how rapidly CSP feature sets and security controls evolve.
4. Choosing the Right Partners and Integrators
In a fast-moving cloud ecosystem, vendor and integrator selection has long-term security implications. Partners who have worked across multiple CSPs — and who have direct experience with regulated industries or public-sector requirements — bring institutional knowledge that is difficult to build internally in a short timeframe.
For federal agencies in particular, working with integrators who hold relevant certifications (FedRAMP authorisation experience, for example) and who understand compliance frameworks such as NIST SP 800-53 is critical. The same principle applies to commercial organisations operating in regulated sectors such as healthcare or financial services.
Partner selection criteria should include demonstrated multicloud experience, a clear security methodology, and a track record of working within shared responsibility frameworks — not just technical delivery capability.
Looking Ahead: Shared Responsibility at Scale
As enterprises operate across increasingly complex combinations of multicloud, hybrid cloud, and on-premises infrastructure, the shared security model becomes harder to maintain consistently. The information asymmetry between CSPs and their customers remains a structural challenge, and closing it requires CSPs to be more proactive about educating customers on risk — not just providing the tools to address it.
In the meantime, organisations that combine zero-trust architecture, CASB-based visibility, ongoing workforce education, and carefully selected partners will be meaningfully better positioned than those relying on any single control in isolation.
Original source: Forbes.com. This article summarises and expands on the key recommendations from that piece for a DevOps and cloud engineering audience.