CHAPTER 2: OVERVIEW OF EXISTING CLOUD TAXONOMIES AND MODELS
Chapter 1 provided an informal introduction to the main concepts underlying the Cloud computing model. This chapter provides a more formal set of definitions and a common terminology to enable a joint understanding of what is meant by terms such as IaaS, community Clouds and deployment models.
There are a number of different definitions of Cloud computing, with probably the most widely accepted being the definition of Cloud computing produced by NIST.3 The NIST definition describes Cloud computing as being:
[A] model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models.
The five essential characteristics, as defined by NIST, are:
1.On-demand self-service
2.Broad network access
3.Resource pooling
4.Rapid elasticity
The three service models defined by NIST are the familiar terms of IaaS, PaaS and SaaS. These service models are described in more detail shortly.
The four deployment models within the NIST definition comprise the commonly used terms of public and private Clouds together with the less commonly used models of community and hybrid Clouds (though hybrid Cloud is becoming increasingly popular in the enterprise space). Each deployment model is described more fully a little later on in this chapter.
There are some interesting things to note about the NIST model of Cloud computing, one of which is that it focuses on the three main traditional delivery models of IaaS, PaaS and SaaS. New models have emerged since the publication of the NIST definition, notably FaaS and the different, but often related, model known as serverless computing. As both the FaaS and ‘serverless’ models are likely to become increasingly popular over the next few years, particularly with respect to the implementation of microservices architectures, we will consider the security of such models in this book.
Whilst this book is relevant to Business Process as a Service (BPaaS), and, indeed, to many of the other *aaS terms that have been coined since the publication of the NIST definition, it is structured so as to consider IaaS, PaaS, SaaS and FaaS in turn. Those deploying other *aaS models should take the relevant guidance and adapt it to their purposes.
Service models
Infrastructure as a Service (IaaS)
In their definition, NIST describe Cloud IaaS as the model where:
The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g. host firewalls).
The most popular IaaS services are those offered by the ‘Big 3’ comprising Amazon Web Services (AWS), Microsoft Azure and the Google Cloud Platform (GCP); however, some of the major systems integration companies, such as IBM and HPE, also offer IaaS specifically targeted at enterprise users. You can also find smaller local Cloud service providers (CSPs) offering ‘sovereign’ Cloud services, i.e. Cloud services hosted and supported from a single host country, which target those organisations with specific regulatory or national security requirements necessitating that data and services remain in-country.
An example of a more focussed IaaS is that of companies offering Disaster Recovery as a Service (DRaaS) whereby organisations can store machine images and data in a Cloud-based service ready for use in a disaster scenario rather than building a secondary data centre. Another example of an IaaS is that of desktop as a service which enables end users to access their company 'desktop' over the Internet, with the desktop infrastructure itself being hosted within a Cloud provider and shared with other clients.
The primary selling point of IaaS is that the Cloud provider has already invested in providing the infrastructure and so end user organisations only have to concern themselves with the operational expenditure of using the service rather than the capital expenditure of building their own services. Consumers, therefore, pay for the capacity that they actually use rather than having to pay for servers sitting idling in their data centres. Furthermore, IaaS enables the speedier deployment of new resources, with new server images being available to consumers in a matter of minutes rather than months, as may be the case for those organisations needing to manage complex procurement and deployment processes. Those resources can then be released again should demand recede, at which point the organisation bears no further costs – a marked contrast to the traditional model. IaaS also promises to release headcount currently assigned to physical server management to tasks that offer more perceived value to the business.
Many enterprises are adopting IaaS for mission-critical production services across a wide variety of sectors. ‘Cloud First’ is the dominant IT strategy for both the FTSE350 and the UK government. It is now extremely rare to find an organisation that is looking to build new physical data centres; few organisations see building and operating data centres as a core business activity.
There are a number of reasons why some organisations may still be resisting a move to IaaS, with security being one of those factors.
•It is potentially more expensive to run a 24/7 service, with relatively constant levels of demand, on the Cloud. Clouds tend to be cheaper for short-term or bursty applications – consistent loads can be cheaper to host on-premises, particularly where organisations are not willing to re-architect services to take advantage of the elastic nature of the Cloud.
•Certain legacy technologies, such as mainframes, cannot easily be migrated to the Cloud. Mainframe workloads are now being moved to the Cloud, but this is certainly not as straightforward as moving a virtual machine from VMware ESX to AWS EC2 or Azure. Furthermore, mainframe applications may require substantial data transfers to and from the Cloud provider and this may create greater costs.
•Discomfort with the ‘follow the sun’ support model of the underlying Cloud platform. Whilst the Cloud provider's physical infrastructure is, obviously, supported in the host geography, the higher levels, such as the hypervisor layer, may be supported from outside the host region. This situation can cause difficulties for those organisations subject to blanket compliance requirements demanding data, services and support be hosted within a specific geography.
Platform as a Service (PaaS)
NIST describe Cloud PaaS as the model where:
The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.
The most well-known examples of PaaS include Microsoft Azure, Google AppEngine, AWS Elastic Beanstalk, Heroku and the Force.com platform. In addition to those platforms that allow the Cloud consumer to simply run their code, the PaaS term is also commonly used to describe other services that sit in-between the IaaS and SaaS definitions. Examples of such PaaS services include the Azure data analytics offers and the Service Now platform where customers are able to develop and extend upon the provided service.
PaaS offerings build on the advantages of the IaaS model by taking away the overhead of server administration from consuming organisations. Developers get direct access to the development environment and can increase or decrease their compute resources as and when they need; project delivery is no longer dependent on server installation lead times.
As we shall see later in the book, PaaS is perhaps the hardest of the three delivery models to secure as the responsibilities for delivery of security services is distributed across the provider and consumer much more widely than in the other two service models.
Cloud interoperability and portability is the subject of many industry initiatives, including work by the Open Group,4the International Organization for Standardization5 (ISO/IEC 19941:2017) and the Object Management Group6; however, both issues remain problematic with no standard being widely adopted by the major Cloud providers. Whilst it constitutes an issue for all Cloud models, the potential risk of lock-in is more pronounced with PaaS than with either IaaS or SaaS. PaaS providers may support specific frameworks, APIs, identity management services and databases that may not be compatible with those offered by other providers or traditional on-premises products. In practice, this makes it very expensive to move from one PaaS provider to another as the developed application must be recoded (ported) to utilise the APIs, frameworks and other features offered by the platform of any alternative provider.
The PaaS model tends to be very attractive to those organisations needing quick delivery of Internet-facing services and those organisations (such as start-ups) that do not have the resources to host or manage their own servers at the operating system level. The PaaS model is also increasingly popular with the enterprise market, particularly in the area of big data analytics and machine learning.
Software as a Service (SaaS)
NIST describe Cloud SaaS as the model where:
The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based email), or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.
Salesforce.com, a company that offered Cloud services before the term ‘Cloud’ itself was coined, is without doubt a pioneer in the area of SaaS. Other examples of well-known SaaS applications include Office365, SuccessFactors.com, Google Docs and Concur.
With SaaS, organisations will typically access a specific software application (such as a customer relationship management application) via a web browser. This means organisations only need to consider the business usage of that application and the provision of devices capable of accessing the Internet – concerns around servers, operating systems and application development are no longer relevant. This model can be very attractive to business executives, particularly if the relationship between business and IT representatives has been strained by past perceptions of poor or unresponsive IT delivery.
The SaaS model is probably the most commercially successful of the three delivery models, perhaps in part due to the previous industry flirtation with the Application Service Provider (ASP) model. Enterprises appear to be more comfortable making use of specific services hosted in the Cloud than they are with the idea of making more general purpose usage of Cloud-based services. SaaS can appear to offer genuine business enabling services whereas PaaS and IaaS may appear to the business as simply different ways of doing IT.
There are a number of specific, security-focussed SaaS offerings, including email security, web content filtering, identity as a service, vulnerability assessment and anti-malware to name a few. These ‘security as a service’ offerings are often pitched as providing security expertise for those organisations that cannot provide such expensive expertise internally.
Function as a Service (FaaS)
As noted earlier, NIST do not currently publish a definition for FaaS or the related term ‘serverless’. There are a number of different definitions relating to both terms, but no widely accepted standard; that being the case, I feel little guilt in putting forward my own definitions in this book!
Let us define serverless as:
The capability provided to the consumer is to deploy functionality onto the Cloud by accessing utility services via the APIs offered by the provider. The consumer does not manage, control or have visibility of the underlying Cloud infrastructure, including its network, servers, operating systems or storage, but has control over the deployed applications.
The key point here is that the consumer has no visibility of the underlying infrastructure as services are accessed purely by application programming interface (API). In other words, whilst physical servers are providing the services within the realm of the Cloud provider, these services appear ‘serverless’ to the consumer who only ever interacts via API. The canonical example of a serverless technology is AWS S3 (Simple Storage Service); in this case, consumers simply call the S3 API to PUT or DELETE data objects but have no visibility of the underlying infrastructure.
FaaS is a form of serverless technology and an evolution of the PaaS model. The most popular FaaS services are AWS Lambda, Azure Functions and Google Cloud Functions.
We will define FaaS as:
The capability provided to the consumer to deploy event-triggered, time-limited functions on the Cloud without requiring an overall process to be running at all times. The consumer does not manage, control or have visibility of the underlying Cloud infrastructure including its network, servers, operating systems or storage, but has control over the deployed applications. Scaling is the responsibility of the Cloud provider.
In general, FaaS services charge per number of executions, execution time and related factors, i.e. if a particular function is never triggered then there will be no charge (other than for associated storage of code or data). Functions can be triggered by a variety of events including provider-specific events (e.g. changes to the contents of an AWS S3 bucket), the receipt of an HTTP request or the identification of an event in a data stream. FaaS functions are time-limited; for example, an AWS Lambda function has an execution limit of 15 minutes whilst an Azure Function has a default execution time limit of 5 minutes (configurable to a maximum of 10 minutes) under the Consumption hosting plan option. If a function is not completed within those time limits, it may be terminated by the Cloud run-time.
FaaS services are commonly used to assist in the automation of IT operations, e.g. as part of DevOps initiatives (or, in the context of this book, DevSecOps initiatives), due to their ability to automatically respond to defined events. Another common use case for FaaS is the cleansing of data, e.g. to prevent regulated data from being transferred outside of an assured environment.
FaaS is also becoming one of the primary technologies used to implement microservices architecture, i.e. applications that are decomposed into modular components. Enterprises have the option of containerisation of microservices components or using FaaS, and some of those that have not invested in the likes of Kubernetes and Docker to provide containerisation are now deciding to avoid that complexity and move to FaaS.
The ephemeral and distributed nature of the FaaS model presents a number of novel challenges from the perspective of security that we will explore later in this book (see chapter 12).
Deployment models
Public Cloud
The public Cloud model is the archetypal Cloud model; the services are open to all-comers, individuals, enterprises, governments, your collaboration partners and your competition. The key point is that there are no real security barriers governing who can register to access the shared service. The low barrier to entry (typically a need for a credit card and an Internet connection) is one of the major selling points of the public Cloud model.
NIST define a public Cloud as one where:
The cloud infrastructure is provisioned for open use by the general public. It may be owned, managed, and operated by a business, academic, or government organization, or some combination of them. It exists on the premises of the cloud provider.
Examples of public Clouds include Amazon Web Services, Microsoft Azure, the Google Cloud Platform, Salesforce.com, Office365 and most other well-known Cloud services.
Private Cloud
The term 'Private Cloud' is one of the more contentious concepts within the area of Cloud computing. Some commentators such as Werner Vogels of Amazon7 have argued that private Clouds do not exist, with the implication that those organisations which believe themselves to have a private Cloud in fact only have a virtualised data centre. I must admit that the distinction between a virtualised data centre and a private Cloud can be hard to define; however, I do see merit in the idea of a private Cloud. In the public Cloud the economies of scale are realised through the sharing of resources, such as CPU cycles and storage across different organisations. However, in the private Cloud model the economies of scale come from the sharing of resources across different cost centres within the consuming organisation.
Of course, in the private Cloud model there are much lower savings on capital expenditure compared to the public Cloud as the consuming organisation must still invest in the IT and physical hosting infrastructure. However, a private Cloud is still likely to be cheaper to operate than a more traditional infrastructure due to the lower footprint of a shared, multi-tenant (between cost centres) virtualised IT estate. A perception that private Clouds are more secure than their public equivalents is one of the main drivers for organisations to build their own Cloud. The other major driver for organisations adopting private Cloud approaches is a risk-averse interpretation of regulatory requirements. These ideas will be explored later in chapter 6, which discusses some examples of regulatory requirements relevant to Cloud usage.
NIST define a private Cloud as being where:
The cloud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third-party, or some combination of them, and it may exist on or off premises.
The major public Cloud providers do now allow their customers to procure dedicated instances and dedicated hardware (i.e. compute resources that are not shared with other tenants); this allows them to offer private Cloud services albeit at greater cost than their multi-tenant offers.
Community Cloud
Community Clouds form the middle ground between public and private Clouds and could be viewed as equivalent to a gated community. Community Clouds are only open to members of the community with rigorous registration procedures to be completed prior to access being granted. Once granted access to the community, there would typically be a set of minimum security controls that member organisations must implement in order to protect the overall community. Community Clouds are more cost-effective than private Clouds as the cost of building and operating the services are shared across all of the organisational tenants.
NIST define community Clouds as being those where:
The cloud infrastructure is provisioned for exclusive use by a specific community of consumers from organizations that have shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be owned, managed, and operated by one or more of the organizations in the community, a third-party, or some combination of them, and it may exist on or off premises.
Secure government Clouds, open only to departments and their executive agencies, are good examples of community Clouds. Other such community Clouds exist in specific private sector industries, notably defence.
Hybrid Cloud
NIST define the Hybrid Cloud model as representing the model where:
The cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds).
The initial driver for implementing a hybrid Cloud model was the belief that this would ensure the effective management of spikes in demand that would exhaust the resources available to a more private deployment model. For example, organisations hosting a private Cloud could draw upon the CPU resources of a public Cloud should demand become too great for the private Cloud to service. However, the demand for such ‘Cloud-bursting’ has not proved to be as great as expected.
The hybrid model is now much more popular with those enterprises that are unable to move all of their IT services to the public Cloud, either as a consequence of other choices or of their interpretation of strict compliance requirements. In both scenarios, it is likely that there will be a requirement for data, and potentially for workloads, to transfer across the private and public Cloud environments in a controlled manner.
In my opinion, hybrid Clouds represent the worst of all options from a security perspective; organisations must now cover off all security issues for both the private and public Cloud models. For example, should an organisation be subject to specific compliance requirements (e.g. the EU General Data Protection Regulation (GDPR) in relation to data protection) then they must now ensure that these requirements are met in both the private and the public Clouds. Difficult problems must, therefore, be solved twice, quite likely using different solutions depending upon the Cloud services adopted. The one obvious security advantage of the hybrid approach is the likely improved availability of services provided by the additional capacity hosted on the more public Cloud service. As an example, a number of charities burst to public Cloud services to manage huge spikes in demand following major disasters.
The NIST definitions may be the most widely accepted, but that does not mean that they are the only set of definitions. As you would expect, the major analyst firms, such as Gartner, IDC and Forrester, have all produced their own definitions of Cloud computing and/or Cloud services, as has the ISO. I am not going to detail each of the competing definitions of Cloud services (Google can help you find them if you feel the need); I believe that the NIST definitions are now the clear leader and provide the basis for a common terminology, particularly as they have been adopted by cross-industry groups such as the Open Group and the Cloud Security Alliance.
This chapter has introduced the NIST definitions of Cloud computing – this is important as the terms IaaS, PaaS, SaaS, public, private, hybrid and community will be used many times throughout the rest of this book. Now we have a common terminology, it is time to discuss the security considerations of Cloud adoption.
3 https://csrc.nist.gov/publications/detail/sp/800-145/final.
4 https://collaboration.opengroup.org/cloudcomputing/i14y/.
5 www.iso.org/standard/66639.html.
6 www.omg.org/cloud/deliverables/CSCC-Interoperability-and-Portability-for-Cloud-Computing-A-Guide.pdf.
7 www.ciozone.com/index.php/Cloud-Computing/Beware-of-the-Private-Cloud.html.