We’re all familiar with the shared responsibility model championed by cloud providers like AWS, Azure, and GCP: platform providers secure the cloud infrastructure, while customers are responsible for securing their usage and configuration of services. But how well is this model holding up in practice?

Not great, as it turns out. A staggering 88% of cloud security breaches are attributed to human error and misconfigurations. Another report found that 95% of organizations experienced some form of cloud breach. So, what exactly is going wrong?

Key Challenges:

• Complexity: The typical understaffed CloudOps leader managing 20 development teams, 200 cloud accounts, 25,000 roles, hundreds of services, and thousands of risky permission settings across three clouds does not feel in control.  They are drowning.
• Visibility Overload: Security teams are bombarded with alerts about poorly configured permissions, but app vulnerabilities and exposed S3 buckets often take priority with developers, leaving permissions overlooked.
• Skill Gaps: Everyone knows that iam* is powerful, but do you know that misconfiguring AWS CloudFront can lead to website defacement or that Amazon SageMaker can be used to escalate privileges? What about the other 4000+ sensitive permissions across hundreds of cloud services? Allowing unrestricted access to sensitive permissions is like letting everyone in your organization reconfigure the data center firewall or proxy.

The Bottom Line

Yes, cloud environments can be secured, but the process remains complex and chaotic.  

There are plenty of tools that highlight the scale of the problem, but fixing it? That’s another story. And while everyone recognizes the issue, it’s often seen as someone else’s problem.

From Visibility to Action: Three Strategies to Cement Responsibilities and Improve Cloud Security

So, what can be done to move from endless visibility to meaningful action? Here are three actionable steps:

1. Adopt a “Deny First” Model to Minimize Complexity and Attack Surface

The complexity of cloud platforms isn’t going away anytime soon. For cloud providers, unrestricted access for developers is a feature, not a bug. To combat this, we propose shifting from an “Allow All” model, which multiplies complexity, to a “Deny First” approach that constrains it.  Yes, you must enforce this in your cloud.

If a service, permission, region, or role is unused, block it immediately and by default. If developers need access to sensitive permissions or new services, they should request and justify it, ensuring careful oversight.

2. Remediate Centrally if You Can, Send to Developers if You Must

Developers are burdened to fix security issues that do not need to be put on their plate.  Security strategies that depend on flawless Infrastructure as Code (IaC) are unrealistic.

Instead, cloud platform and security teams should increase centralized control, reducing the flow of alerts to development teams. Cloud providers now offer centralized policy engines that allow for automated fixes for unused resources. For instance, most overprivileged IAM issues can be resolved without any code changes. We’ve seen firsthand how centralizing AWS Service Control Policies (SCPs) has helped customers instantly eliminate 10,000+ security issues, problems that would otherwise land on developers’ plates—or worse, go unresolved.

3. Implement Real-Time, On-Demand Provisioning for Services and Permissions

Security teams can’t afford to slow down developers by taking hours to provision access. A deny-first model only works if there’s a fast, responsive system for on-demand access and privilege restoration. Developers need access to cloud services and permissions in real time to maintain productivity.  Again, we successfully do this for our customers by leveraging ‘Chat-Ops’ in Slack and Teams to ensure rapid response to permission requests.

Conclusion

Cloud security is a shared responsibility, but it doesn’t have to feel like a shared burden. By adopting a deny-first model, centralizing remediation, and providing real-time provisioning, organizations can regain control of their cloud environments—without overwhelming developers, burdening cloud platform teams, or sacrificing agility.

*** This is a Security Bloggers Network syndicated blog from Sonrai | Enterprise Cloud Security Platform authored by Brendan Hannigan. Read the original post at: https://sonraisecurity.com/blog/avoiding-no-responsibility-cloud-security-model/