The shared responsibility model is a framework used by cloud service providers and their customers to define who handles cloud security across a cloud environment: the physical data centers, hardware, and the virtualization layer that sits on top. When you share security responsibilities with a cloud provider, your data, user identities, and access management are always your responsibility. Other security responsibilities vary with the service type, or service model (IaaS, SaaS, or PaaS), and are usually written into a service-level agreement (SLA).
Key takeaways
- The core split in a shared responsibility model: cloud providers secure the cloud infrastructure and you secure the data, identities, and access management.
- The shared responsibility model applies whether you run on-premises or in a public cloud, private cloud, or hybrid cloud.
- Shared responsibility also covers cloud operations, such as backups, availability, and monitoring—not just security issues.
- Misconfiguration and human error on the customer side—not provider failure—drive most security breaches.
- When you use a managed cloud database, like MongoDB Atlas, it handles patching, default encryption, and infrastructure, and you manage access, configuration, and data.
Table of contents
- What does the cloud provider secure, and what do you secure in the shared responsibility model?
- Who secures what when IaaS, PaaS, and SaaS models are used?
- Which three responsibilities does the customer always own?
- What causes most cloud security breaches?
- Best practices for the shared responsibility model
- Who is responsible for backups and availability?
- How MongoDB Atlas fits into the shared responsibility model
- Get started with MongoDB Atlas
- Related resources
- FAQs
What does the cloud provider secure, and what do you secure in the shared responsibility model?
Moving to the cloud splits ownership into two. The cloud provider secures the cloud itself—the underlying infrastructure of the facilities, hardware, and virtualization layer. You secure what you put into the cloud—your data, applications, and access control. Before the cloud existed, there was no shared responsibility. Many organizations ran their own data center and owned every layer: the physical building, servers, operating system, patches, and data.
Amazon Web Services (AWS) calls this division of cloud computing security “of” the cloud (which it owns) and security “in” the cloud (which the customer owns). Where that line is drawn between the two isn't fixed—it changes with the service model and applies whether you choose a public cloud, private cloud, or hybrid cloud.
Who secures what when IaaS, PaaS, and SaaS models are used?
Each service type draws the line of control in a different place.
Infrastructure as a service (IaaS) gives you the most control—and the broadest set of security responsibilities.
The provider handles infrastructure security: the physical data center, the hardware, and the virtualization layer—all the way down to the physical security and physical access controls at the facility.
You handle everything above it: the operating system, the runtime, your applications, and your data. That makes application security, code security, data security, and access control all yours.
Platform as a service (PaaS) gives the provider more to manage, so your security responsibilities are fewer.
The provider handles the infrastructure, the operating system, and the runtime.
You handle your application code, its configuration, your data, and access.
Software as a service (SaaS) hands almost everything to the provider, leaving you the smallest set of security responsibilities. Many public cloud services work this way.
The provider handles your entire stack, from the infrastructure up through the application itself.
You handle user access, account settings, and the data you put into the application.
The table below shows where responsibility sits across all three cloud service models.
Which three responsibilities does the customer always own?
Some security responsibilities never transfer to the cloud provider, no matter which service model you use. You can bring in help to do the work—an internal security team or an outside provider—but you stay accountable for it.
Data security: The cloud provider secures the infrastructure data sits on, but data protection is your responsibility. Who can see it, how it’s classified, and how it’s protected is up to you.
Identity and access management: When everything was in-house, you could put a firewall around your entire system to keep it secure. With the shared model, part of your system is in the cloud, so you lose that built-in security. This means it’s up to you to manage user access and enforce least-privilege controls; users only get the permissions they need through role-based access control (RBAC) and multi-factor authentication.
Endpoints: Laptops, tablets, phones, and any other devices that connect to your cloud resources are your responsibility to secure. A managed platform cannot protect against a compromised device or a stolen password. For more on protecting data itself, see Why Secure Databases Matter.
What causes most cloud security breaches?
Misconfiguration on the customer side of the cloud environment, not provider failure, is the leading cause of security breaches. Attackers rarely break into a provider's data center. They look for exposed entry points on the customer side, such as:
An exposed storage bucket: Cloud file storage accidentally left open so anyone on the internet can access it.
An over-permissioned access role: An account granted more access than it needs.
An unpatched system: Software running with known security vulnerabilities because the security patches that fix them were never applied.
What are the best practices for the shared responsibility model?
The customer side of the model is where most breaches begin—and it’s in your control to mitigate them. The habits below can help you stay on top of your cloud security responsibilities, strengthen your cloud security posture, and keep a small mistake from turning into a breach.
Decide who owns what up front
Read the provider’s shared responsibility matrix. It’s the chart that lists each security task and marks whether the provider or the customer is responsible for it. Usually broken down by service model, most providers offer one; it’s similar to the IaaS, PaaS, and SaaS chart above. Keep one for the cloud services you use, and share it with your team.
Enforce least privilege
Give each user, application, and process the minimum access it needs, and use tight access controls to keep user access in check.
Manage it at scale with role-based access control: define roles with set permissions and assign people to them, instead of granting access person by person.
Require multi-factor authentication wherever possible.
Review permissions on a schedule and remove access that's no longer needed.
Use temporary credentials with expiration dates instead of long-lived access keys—a leaked long-lived key stays valid until someone catches it, while a temporary one expires on its own.
Encrypt your data
It’s your responsibility to encrypt your data—it’s not the cloud provider’s job. Turn on encryption at rest (where the data is stored), in transit (as it moves through the network), and in use (data actively being processed by software or hardware)—so exposed, sensitive data is unreadable without a key. Keep track of who holds those keys.
Turn on logging and monitoring
Monitor your cloud environment: keep track of who did what and when with an audit log. Set alerts for unusual activity, such as a sign-in from a new location or a sudden spike in data access. This kind of monitoring supports threat detection, giving your security team an early signal. Without logs, the problem is harder to pinpoint and investigate afterward.
Automate configuration checks
A scheduled review of permissions only catches problems when you run it. Automated configuration checks scan your cloud environment in the background and flag issues as they appear, such as a permission that was never removed or a port that was left open, so they don’t sit unnoticed between reviews. Treat these automated security controls as part of your everyday operations.
Restrict network access
Limit which networks and addresses can reach your resources, and opt for private connections instead of exposing a service over the internet. Strong network security—network controls, firewall rules, virtual networks, and private endpoints—shrinks the attack surface. A private connection links your systems to a resource over a network path that never touches the public internet, so there’s no public address for an outsider to discover or try to hack into.
Read your provider’s compliance reports
Attestations like SOC 2 and ISO 27001 tell you which security measures the provider already covers, so you can focus your effort on the security obligations that are yours. Review them at least once a year, and fold them into your broader risk management and business continuity planning.
Who is responsible for backups and availability?
Security is the most discussed part of the shared responsibility model, but operations are shared, too. Backups, high availability, disaster recovery, business continuity, performance, and monitoring are all divided between you and your provider across your cloud environment. The provider supplies the capability; you decide how to use it.
How MongoDB Atlas fits into the shared responsibility model
Most discussions of the shared responsibility model include only two parties: the cloud provider and the customer. That approach leaves out a third. When you run a managed database service (DBaaS) like MongoDB Atlas, all three parties share the work:
The cloud provider (AWS, Microsoft Azure, or Google Cloud) secures the physical infrastructure your workloads use.
The vendor (MongoDB) runs and secures the database service on top of it.
You manage access, configuration, and your data.
Where MongoDB Atlas sits depends on how you run it.
If you run MongoDB yourself (IaaS)
The cloud provider handles infrastructure security for the hardware beneath you—everything else is yours. You patch the operating system and the database; configure the firewall and the rest of the security configuration; manage backups; and handle scaling and high availability.
If you use MongoDB Atlas (DBaaS)
MongoDB Atlas is a managed database service, so it takes on the work that would otherwise fall to you, such as patching, default encryption, tenant isolation, and the underlying hardware and security features. What stays with you is the security configuration of your cloud workloads: access, configuration, and your data. The table below breaks them out row by row.
MongoDB Atlas also carries its own certifications—SOC 2, ISO 27001, PCI DSS, and HIPAA support—you inherit compliance at the platform layer. That narrows your own work to your configuration and data, not the infrastructure beneath it.
MongoDB Atlas is sometimes grouped with PaaS, but it sits a layer above that platform, at the data and application level. See how managed databases handle this work.
One mistake to avoid
MongoDB Atlas lets you set up an IP access list that controls which addresses can connect. Don’t open it to every address with 0.0.0.0/0—use specific IP ranges or private endpoints so only your own systems can connect.
Get started with MongoDB Atlas
The shared responsibility model is easier when the platform handles more of the work for you. MongoDB Atlas secures the database and infrastructure and encrypts your data by default, which leaves your team to focus on the many security responsibilities you own. For the full breakdown of what MongoDB manages and what you manage, see the Atlas Shared Responsibility Model. To start building, create a free cluster.
Related resources
- Database as a Service (DBaaS) — Find out how a DBaaS runs and manages your database in the cloud, and where it sits in your tech stack.
- Managed Databases — See what a provider takes on with a managed database: security, backups, monitoring, and scaling.
- Public, Private, and Hybrid Cloud — Compare the three cloud deployment models and when each one fits a given workload.
- Infrastructure as a Service (IaaS) — Understand how IaaS delivers virtualized compute, storage, and networking as the foundation of the cloud.
- Platform as a Service (PaaS) — Explore how PaaS gives developers a ready-made platform to build on without managing the infrastructure underneath.
- What Is Multicloud? — Discover what a multicloud strategy involves, from avoiding vendor lock-in to managing the added complexity.
- Cloud Computing Stack — Trace how cloud services stack up, from low-level infrastructure to fully managed applications.