Most people who have worked with cloud technology are probably familiar with the typical Shared Responsibility Model (SRM) diagram shown below. But be warned, this representation of responsibility can be extremely deceptive and a leading cause of cloud chaos.
The typical SRM diagram shows which layers of the technology stack customers and providers are responsible for. In an On-Premises model, this shows the customer is responsible for the entire tech stack. They manage everything from the building that contains the data center, to the applications running on the servers, and everything in between. On the opposite end of the spectrum, in the SaaS model, the provider is responsible for almost the entire tech stack.
So, why is the shared responsibility model deceptive?
Because a critical area of responsibility is entirely missing! Not only is it missing from SRM diagrams like this one, but many organizations who have adopted cloud technologies fail to invest time in these missing responsibilities, and we see the repercussions of this daily:
SaaS applications procured without technology staff involvement, leading to integration, security, and compliance issues - because per the diagram, the tech stack is entirely managed by the vendor!
Improperly secured public cloud networks and storage leading to massive fines and reputational damage from the resulting data breaches - because per the diagram, networking and storage are the vendor's responsibility!
Spiraling costs when migrating and building workloads in a cloud hosting model - because finance teams are no longer reviewing your budgets in a cap-ex model, and neither is your provider!
The reality is that some crucial detail is missing from SRM diagrams like this one. While it’s unlikely (we hope) that technology teams are basing their cloud strategy directly around these diagrams, it certainly doesn’t help with educating teams on how to manage cloud services effectively.
Enter the Cloud Platform
By adding the “Cloud Platform” itself into the model, we can start to understand what responsibilities are missing:
The “Cloud Platform” is the foundational layer of the platform you are operating. Essentially it represents the administrative interface used to manage the platform itself. For SaaS applications, this is the interface where users, roles, single sign-on, and security settings are configured. Think of the admin portal for Microsoft Office 365.
Office 365 is a SaaS platform, so according to the typical SRM we are only responsible for the data. Sounds great! We buy Office 365, and our users get straight to work! But the reality is different. We (the customer) are responsible for much more than just the data. Users need to be configured to access the application, policies might be created for how data can be shared, and labels might be configured for classification of sensitive information. These are just three examples out of hundreds of potential responsibilities for administrators of an Office 365 environment.
For IaaS and PaaS platforms, the foundational layer would be the Azure or AWS portal itself. Time should be spent in these areas to ensure that your business stays secure, compliant and operates with maximum efficiency and scalability.
Some other examples of Cloud Platform responsibilities are show below:
One important point of note is that some of these responsibilities may be handled higher in the stack. For example, you may have security policies or budgets enforced at the application layer in a PaaS model. But there are still going to be platform-wide security and cost concerns that should be addressed before moving production applications to a cloud hosting model. This foundational layer is often overlooked, leading to a poorly secured and hard to scale environment.
Implementing a technology platform is like building a house – you should probably pour the foundation and put up some walls before decorating the bedroom. (HINT: The foundation is your cloud platform, and the bedroom is your application!)
Summary
Many of the diagrams representing the shared responsibility model miss a critical component of responsibility. They fail to consider the underlying cloud platform and the customer responsibilities that go with it. Adding another layer to these SRM diagrams serves as an important visual reminder that these responsibilities exist and that they are important.
Next time you see a diagram that omits these responsibilities, remember that there is an entire platform to govern, not just the services that run on top of it.
Next time your business unit decides to purchase commercial off the shelf SaaS products, loop in your technology department first, so that they can help you to secure and manage the underlying platform. It’s much easier to do this in the beginning and your technology team will thank you for it!
Next time your development team starts deploying applications to a new PaaS platform, help them to build on top of a foundation that is secure, cost-effective, and compliant before you expose your data to the world!
Get help with your Cloud Platform today!
Principle Choice Tech Solutions are experts in cloud enablement and adoption. We've seen first-hand how organizations can fail to deliver on the cloud's promise of faster, more efficient technology and rapid digital transformation.
With our revolutionary approach to Cloud Adoption, we can help you achieve cloud agility without compromising on security, compliance, cost management or standards.
Get in touch with us today through our Contact Page to start your journey to a compliant, efficient, and more cost-effective cloud!
Follow our LinkedIn page to stay updated on new posts about technology strategy, techniques, and tips.