Adapting the cloud service model to today's needs

You may have come across the diagram below, or a version of it if you’ve done any research into cloud services (and not from under a rock).

David Chou was one of the early pioneers of cloud computing at Microsoft. He used diagrams like this one to articulate the different services models available in the cloud compared to traditional on-premise responsibilities. 

These concepts were first envisioned between 2008 and 2010. A lot has happened in cloud computing since then, and I thought it would be interesting to revisit this model armed with the hindsight of the last 10 years (and through a security lens).

Ransomware and malware

The emergence of ransomware, increasingly sophisticated malware, and zero-day exploits mean enterprises are now looking at more than just applications when it comes to security. Architects are replacing flat, wide internal networks – and their applications and VPN access points publicly exposed to the internet – with workload segmentation and zero trust network access (ZTNA) methods. As ZTNA has taken shape, they now need to consider application presentation (or methods of access) and even the end-user device part of an application’s architecture for a holistic security strategy. 

Insecure cloud deployments and misconfigurations

In 2010, the idea of zero trust as an alternative to the traditional network-perimeter security model was only starting to take shape and many enterprises treated cloud services (outside of SaaS) as simply extensions of their own on-premise datacenters. In these early days of the cloud, infrastructure mistakes and insecure configurations were “hidden” behind the trusted network perimeter. As enterprises become more cloud-native, deployment mistakes have had disastrous consequences, and many are now employing governance and compliance tools to protect against vulnerable deployments. 

A reimagined cloud service model

David Chou published his “final” version of the cloud service model in 2011 as the popular viewpoint of cloud evolved towards the platform “everything as a service” view as opposed to the traditional IaaS/PaaS/SaaS model. While I don’t disagree that the platform is the optimal way to imagine cloud, realistically, large enterprises will continue to use cloud exactly as they used on-premise services for the foreseeable future. That’s why I believe David’s model is still relevant, but needs to be updated to address today’s enterprise challenges.

Modern-day effects

Rise of cloud governance and compliance tools

Just as DevOps morphed into DevSecOps to ensure security was included from the start of development projects, Cloud Security Posture Management (CSPM) and Cloud Native Application Protection Platform (CNAPP) services appeared for similar reasons – to provide automated, secure guardrails for protecting against cloud platform misconfigurations that put enterprises at risk. We now add a “Governance and Compliance” sidebar to each platform type to represent this new functional requirement.

Collision of infrastructure and developer worlds

Various enterprise demands brought the worlds of infrastructure and development together in the form of DevSecOps and infrastructure as code (IAC). Applications and their infrastructure provisioned entirely through automated procedures are more secure, cheaper to deploy, and available for consumption faster. API security is also essential to ensuring  secure automation capabilities. Therefore, I’ve added an “APIs & Automation” sidebar to the model.

Evolution of zero trust architecture

Within the enterprise space, there are two distinct uses of cloud:

1. As an extension or a direct replacement of on-premise datacenters, so IT can flex resources on-demand while avoiding capital expenditures. These services are protected by traditional network perimeter security, funneling all egress/ingress traffic through centralized security stacks.
2. As elastic, portable resources that help drive a mobile-first working environment, with security incorporated natively into the infrastructure.

The second use should be the goal of any enterprise, but it’s not achievable without a fundamental change to the underlying security strategy. That is what zero trust architecture (ZTA) promises to solve. By making identity the security perimeter, instead of the network, enterprises can start using the cloud to its full potential.

By incorporating ZTA into David’s original cloud service model, we add two more layers: 

1. Presentation – ZTA encompasses a gateway, a broker, or as NIST refers to it, an enforcement point between the consumer and the service, so there is no direct internet exposure. David’s model stopped at the front door of the application. We are now taking into account what that front door looks like and how you get to the door to open it.
2. Consumption – Since my version of the cloud service model is focused on enterprise use and ZTA, we must take into account how the app is consumed. This could entail a ZTA agent on the client device to broker connectivity, a proxied session by a CASB, or even a rendered browser when sensitive data is involved.

A few other tweaks

Since David’s final publication, many IaaS, PaaS, and SaaS models have exposed advanced capabilities that blur the management boundaries of the original cloud service model. 

To account for these, I’ve also made the following changes:

• I’ve extended management responsibilities within IaaS down past the Operating System layer, since many enterprises today provision their own OS and manage their own patching, instead of using provided templates.
• Network and storage capabilities within virtualization platforms, both on-prem and in the cloud have advanced so much that I believe they require their own layer in the new model, which I’ve labeled Virtual Resources (black boxes in Figure 2). Advanced functions like virtual network taps and shared virtual storage, on top of the hypervisor layer, are examples.
• I’ve moved the management boundary of PaaS down to the Middleware layer to cater to some of those services blurring the lines between IaaS and PaaS.
• Eagle-eyed readers might notice the extension of the sidebars in the SaaS model extending down to the data layer. Though enterprises have little responsibility for any underlying management of the platform, many of today's SaaS platforms are so configurable that they encroach on PaaS and therefore require the guardrails described above.

Conjecture

And herein lie the reasons David stopped using the model:

• Choices and service types actually dictate where the management boundaries reside, these aren’t hard and fast rules. Enterprises can choose to rely on the cloud provider for all the management available, while some prefer to do everything themselves.  
• Many enterprise-based cloud apps are multi-modal, meaning they use a combination of IaaS/PaaS, and even SaaS, to provide a service. So using this model to describe the architecture becomes unwieldy. While I tend to agree, I do think that with these tweaks, it remains useful for considering the governance and security controls associated with an app’s ecosystem.

Returning to the source

Even if cloud isn’t your thing (and there are scenarios where on-prem is the right choice), I think this captures the guardrails enterprises should consider regardless of where their applications or infrastructure reside. 

I first started this exercise as a fun poke at history, to see how things have changed since this influential diagram first took shape, but it turned into a somewhat serious change review. It is very easy to say that the Netflix’s and Salesforce’s of the world have outgrown the original cloud service model. But for many enterprises, the original model is still very relevant, especially for those that traditionally change at a snail's pace. 

I'm interested in readers' thoughts on these unofficially proposed additions in light of the challenges enterprises face today.

What to read next

Security Service Edge (SSE) reflects a changing market: what you need to know

Navigating the Wild West of cloud workflows