What does “Shared Responsibility” Mean
“Shared Responsibility” explains the demarcation line between what a cloud provider controls and what a cloud consumer controls. In a traditional DIY IT environment, responsibility for everything rests entirely on the business and its IT personnel. Electricity, physical security, hardware, software, and everything else has to be purchased, installed, maintained, and administered by the company directly or through an intermediary. In a cloud environment, responsibility is shared between the cloud provider and the business owner. In addition to defining responsibility, the model explains ownership of cloud resources.
There are a lot of advantages to this type of relationship because it allows the business’s IT staff to take their focus off of certain parts of the environment. There are, however, some things that the cloud provider cannot reasonably take responsibility for. The relationship between cloud provider and business is described effectively using the “Shared Responsibility Model.” The Shared Responsibility Model defines responsibility levels for the three cloud Service Categories outlined in part 1; SaaS, PaaS, and Iaas. Each responsibility level is separated into 6 different responsibilities; Physical, Network, Virtual, OS, Application, and Data. Let me explain what each piece means.
1 – Physical
The physical responsibility of an IT environment refers to everything from the ground to the cables. Data center buildings, physical security, electricity, environmental controls, and hardware are all part of an organization’s physical responsibility. In every cloud environment, the cloud provider is responsible for all physical needs and issues. In most cases, this provides huge benefit to cloud consumers because the physical presence of IT is one of the most expensive parts.
Small businesses in particular, the level of security provided by most cloud providers is far greater than what they can reasonably achieve themselves. Most IT consultants are familiar with a physical infrastructure concept called “Server in a Closet.” This is where a business has their email, Active Directory, and Line of Business applications all running on a single server in a closet. Sometimes the closet is even locked! Getting physical access to a Server in a Closet is usually no more difficult than coming in at lunch time or after hours, picking a couple simple locks (if you’re unlucky), grabbing the server (or planting malware in it), and taking off.
In contrast, physical security of cloud solutions tends to include much more effective security measures like concrete walls, solid steel gates, guard shacks, road barriers, multi-factor authentication measures for entry, man-traps to prevent tailgating, 24/7 CCTV monitoring, and a mountain of other things that can make unauthorized physical access to data nearly impossible. This is compounded by the fact that nobody really knows where all of the data centers are located, exactly (except maybe company executives).
2 – Network
Network responsibility covers everything needed to get bits from one location to another. Routers, switches, Internet connections, and network cables are all part of this. There really isn’t a lot more to this, but modern cloud solutions usually make heavy use of SDN to enable clients so they can customize their cloud network to develop deployments that can mirror their on-prem solutions or improve security of applications.
3 – Virtualization
Virtualization covers all of the physical storage and compute resources available in a cloud environment. Virtualization requires servers to host Virtual Machines (or VMs. this is what we call servers that have been split off of a physical server through virtualization). VM hosts, as they are called, provide the underlying structure that runs VMs. VM hosts control the number of CPUs and amount of RAM assigned to a VM as well as what storage is available for that VM to use. In the cloud, VMs usually consist of a server operating system with an amount of CPU and RAM resources that can be set to a hard limit or that can expand dynamically when resource usage reaches a certain threshold (often referred to as a “scalable” VM).
4 – Operating System
Here’s where the cloud provider’s responsibilities start to transition to the cloud consumer. If an environment leverages IaaS services, they are responsible for determining what OS to install on any cloud-based VMs they create. They are also responsible for purchasing OS licenses (depending on provider and OS, this may already be taken care of), configuring the OS, installing software, supporting that software, assigning storage, managing data, and supporting the OS. In comparison with traditional on-prem virtualization, this level of responsibility would be the same as if you only worried about the actual VMs on a VM host and did no maintenance, management, or support of the VM host. The cloud provider still has responsibility for this if the services provided fall under PaaS and SaaS models.
5 – Application
Applications are, well, applications. This is a little bit of a weird responsibility to explain because it mostly only applies to developers when we talk about cloud services. When you implement a PaaS solution, you’ll assume full responsibility of the application and data processed by that application. In the vast majority of cloud deployments, PaaS services provide infrastructure required to develop custom applications. This means the whole system is provided up to the OS which is pre-configured with an application development and deployment package. Almost all SaaS solutions exist at this level, meaning that SaaS vendors are responsible for everything from physical to here. More often today, though, SaaS vendors will purchase cloud-based PaaS services, develop an application, then sell that application as a SaaS offering.
6 – Data
Data includes all information generated, processed, stored, or managed by the cloud consumer. The state of data in the cloud is entirely the responsibility of the end user. If you lose your data, the cloud provider is not considered responsible for it unless there was a failure in the part of the system they *were* responsible for. Basically, if you purchase cloud services of any kind, you are responsible for backing that data up (if you want), securing it against theft by hackers, and everything else that gets done with that data.
Cloud providers sell access to applications, regardless of what category of cloud they sell. IaaS exists to provide VM infrastructure to support applications, PaaS is made up of a group of applications meant to help software developers. SaaS is a purpose-built application available in the cloud. The applications cloud providers sell can do anything with the data, but the data is owned and maintained entirely by the cloud consumer.
That said, most cloud providers provide functionality, features, or tools that you can use to protect your data, whether that is archiving tools to prevent data loss, multi-factor authentication tools to secure access to data, spam filters, firewalls, and a huge list of more features and tools. It is the cloud consumer’s job to use those tools to protect their own data.
One major question I’ve heard involves cloud providers’ access to data. When properly designed, a cloud environment should allow the cloud provider no direct access to any customer data without first receiving permission in some way. However, some cloud providers are less than ethical about this and will scan client data for marketing clues and insights to help advertising partners sell more product with targeted ads or other marketing techniques. Be wary of using solutions that do this, as they are rarely worth the cost saving involved.
Sharing Responsibility
The share of responsibility that each part of a cloud environment shares depends entirely on what services are being sold. If there is a single cloud provider that sells directly to a customer, the responsibilities are fairly well spelled out. If a vendor sells access to a SaaS solution, the share of responsibility gets a little muddier. In general, though, the basic share of responsibility between a cloud provider and cloud consumer is shown below.
The visualization is fairly simple but should help you understand the different responsibilities held by the different parties in a cloud deployment scenario. This version is fairly simple, but consider a situation where an organization creates and sells a SaaS solution by developing the software on a PaaS contract with Azure or AWS. With this scenario, the shared responsibility model goes from two parties to three. Usually, this means a cloud provider like Amazon or Microsoft is responsible for everything up to the application level, the SaaS vendor is responsible for the application, and the SaaS client is responsible for their own data. More often than not, SaaS vendors don’t reveal the kind of infrastructure they use, meaning you could have data in a SaaS vendor’s own data center, Azure, AWS, or other environments without any kind of disclosure.
The weirdness of this multi-party relationship can have some humorous results, though, such as the situation where an Azure cloud failure caused a failure in a SaaS-based sales and shipping application. This, in turn, caused serious issues with purchasing on Amazon for several hours. The irony of Amazon sales failing because of a fault in Azure had me chuckling for a little while.
Ownership
One very important thing to understand about the responsibility model is that the division of responsibility is also a division of *ownership*. The benefit of having responsibility over something in the cloud is that you also determine what happens with that data (preferably). For instance, in an IaaS environment, the cloud consumer has responsibility for developing and configuring Virtual Machines and applications. Well, they also own the virtual machines and can do anything with them that they choose, including move them from cloud to on-prem or to a different cloud provider. Providers allow various levels of ease when moving VMs, but it *should* be at least possible if the cloud provider is legitimate and following this model.
Security
Cloud security is a sticky subject in many respects, and the responsibility for who secures a resource in the cloud is confusing without an understanding of the Shared Responsibility Model. Many organizations go into the world of cloud services thinking that they have no need to worry about security. In some respects, that is true. But if you look at this model, you can see that every organization that consumes cloud services of any type has at least some responsibility for securing resources. At the minimum, everyone in the cloud must ensure their own data is secure. Cloud environments like Office 365 provide many different tools to aid companies in securing resources, but in the end, the IT staff of each organization is responsible for using those tools.
You can’t hold Microsoft responsible for a user’s mailbox being hacked when you don’t enforce secure password practices or implement multi-factor authentication. Similarly, you can’t hold Amazon responsible if the administrative account for your AWS environment is compromised and someone destroys all of your company’s data or holds it ransom. If, however, the data center that hosts your cloud data is breached and your data is stolen, you can hold the cloud provider fully responsible for losses incurred as a result of that breach. This makes the responsibility for running a cloud environment extremely heavy because failing to secure a client’s data can destroy a small cloud provider.
Moving On
After these first three parts to this guide, you hopefully have a better picture of what the cloud is, the technology that underlies it, and what life in the cloud is like. For the next part, we’re going to step back a bit and go over some cloud concepts that seem to be more about marketing and buzz words than they are substance. Specifically, we’ll go over Private Cloud, Hosted Cloud, Hardware Rental, and Data Center Sharing. All of these concepts are often marketed as cloud systems, but don’t really meet the accepted definition of a Cloud solution.
More Parts
And here’s the links to the other parts of this guide, in case you got here directly and want to learn more.
AC Brown’s Guide to the Cloud – Part 1 – The Basics
AC Brown’s Guide to the Cloud – Part 2 – Cloud Architecture
AC Brown’s Guide to the Cloud – Part 3 – Shared Responsibility Model
AC Brown’s Cloud Guide – Part 4 – Cloud Service Providers
