![]()
Part One: Introduction
Part one provides the foundation for the rest of this book, as it introduces the concepts embodied within Cloud Computing, describes the associated security threats, and lists a few of the existing industry initiatives dedicated to improving the security of Cloud services.
Part two introduces a number of security architecture concepts and a conceptual security reference model. This model is then applied to the different Cloud service models of Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS), showing how the conceptual security services within the reference model can be delivered for each model.
If you are already familiar with Cloud Computing models, terminologies and associated risks, then you could go straight to Part two – although you may find the contents of Part one a useful refresher.
![]()
CHAPTER 1: INTRODUCTION TO CLOUD COMPUTING
Cloud Computing: one of the more evocative labels for an IT delivery model – certainly more so than the “utility computing” label, to which Cloud owes much of its heritage. However, like its rain-bearing namesake, Cloud Computing can be difficult to describe, with many observers having their own perspective on what is, and what isn’t, Cloud. Many people use Cloud services without realising that they are doing so; iTunes, Hotmail, Facebook and Twitter are all examples of Cloud services. However, these are consumer Cloud services, which are aimed at individual users; the security of such consumer services is not discussed within this book.
The purpose of this book is to help those organisations looking to implement those Cloud services aimed at the enterprise SalesForce services, Amazon Web Services (AWS) and Windows® Azure, for example – and to help them do so both in a risk-managed manner and in accordance with their appetite for risk.
Figure 1: Overview of the Cloud Computing concept
Figure 1 shows a high-level representation of the Cloud Computing model. On the left, we have a Cloud Computing provider – essentially a set of servers offering some form of shared IT service. On the right, we have a set of organisations with users and client devices capable of accessing that shared service. In the middle, we have the Internet (or some other delivery network), which acts as the transport mechanism enabling the access devices to connect to the shared service. You can also see some individual users sitting on the Internet, who are just as capable of accessing those shared services as the larger organisations. The shared service on offer could be anything from the Amazon Web Services model of access to compute and/or storage resources, through to the SalesForce, Huddle or Yammer model of access to specific software applications. Regardless of the service on offer, there are a number of key characteristics that the service must display in order to be truly “Cloud”:
- Multi-tenant: The service should (at some level of the technology stack) be shared amongst its users, rather than dedicated to the use of a single consumer. In the case of such services as Amazon Web Services, the multi-tenancy is at the level of the physical hardware and the hypervisor1, which can host virtualised images serving many consumers. In the case of such services as Salesforce, the multi-tenancy sits at the application level – many different consumers access the same instance of the applications on offer. Consumers are, therefore, separated only by the barriers implemented by the provider. Multi-tenancy is a prime differentiator between Cloud services and more traditional outsourcing models, where resources would more typically be dedicated to individual clients.
- Ubiquitous network access: The service should be available to all over a common network. For Public Cloud services, the common network is usually the Internet. For other types of Cloud services, more closed networks – such as government or academic networks – can be used.
- Elastic: The service should be able to respond quickly to spikes in demand. The Cloud consumer should be able to add the additional resources needed to maintain service levels during a spike in demand, and then rapidly release them again once the spike has passed. Cloud providers should look to reduce the amount of manual effort required by consumers to support this elasticity.
- Pay per use: Consumers should be charged for the resources that they actually consume; in the case of infrastructure services, the charge could be calculated according to CPU usage per hour, or according to the GB of data stored or transferred. For Cloud providers offering software as a service, it could involve charging per user per month, rather than charging on the traditional basis of a perpetual license.
- On-demand self-service: Consumers should be able to provision the services they need themselves, without needing to talk to the Cloud provider. With many popular Cloud services, customers can obtain the services they need with only a network connection and a credit card.
That is my view of Cloud – a view heavily influenced by a particularly popular definition of Cloud produced by the American National Institute of Standards and Technology (NIST). The NIST definition of Cloud Computing is discussed in much more detail in Chapter 2. There are a number of services that seek to use the Cloud label, but do not display all of the characteristics described above. A number of service providers have jumped onto the Cloud bandwagon by re-labelling as “Cloud services” those services that would normally just be viewed as shared services. This re-labelling is so common that it has earned its own title: “Cloud-washing”.
This book is not dogmatic about whether or not a Cloud service displays all of the expected characteristics, and the guidance it provides is also generally applicable to wider classes of shared services.
![]()
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 introduces common terminology to enable a shared understanding of what is meant when I use such terms as “Infrastructure as a Service”, “Community Clouds” and “deployment models”.
There are a number of different definitions of Cloud Computing, but the mostly widely accepted is probably that produced by NIST2. 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:
- On-demand self-service
- Broad network access
- Resource pooling
- Rapid elasticity
- Measured service.
The three service models defined by NIST have the familiar labels of “Infrastructure as a Service” (IaaS), “Platform as a Service” (PaaS) and “Software as a Service” (SaaS). These service models will be described in more detail shortly.
The four deployment models identified within the NIST definition comprise those familiar terms of “Public” and “Private” Clouds, together with the less commonly used models of “Community” and “Hybrid” Clouds. Each deployment model is described more fully a little later 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 delivery models of IaaS, PaaS and SaaS. In these days of “everything as a service”, it is sometimes worthwhile to go back to the basics of IaaS, PaaS and SaaS. Whilst this book is relevant to Business Process as a Service (BPaaS) too – and indeed the other myriad *aaS offerings – it is structured so as to consider each of IaaS, PaaS and SaaS in turn. Those deploying models other than IaaS, PaaS and SaaS 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 example of an IaaS offer is Amazon Web Services. However, there are also many major systems integration companies – such as IBM, HP, CSC and Capgemini – that offer IaaS more specifically targeted at enterprise users.
An example of a more focused IaaS would be Storage as a Service (offered by Nirvanix, for example). Using such a service, organisations (or individuals) can store or archive data in a Cloud-based system, rather than hosting it locally. Another example of IaaS is “desktop as a service”, whereby end-users can access their company “desktop” over the Internet; the desktop infrastructure itself would be 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 only for the capacity that they actually use – and not for servers sitting idling in their data centres. Furthermore, IaaS promises 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. Should demand recede, those resources can then be released again – 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.
At present, the primary use cases for IaaS within the enterprise are for development and test services and for those applications that require significant (but short-term) number crunching, such as market simulations or scientific analysis. Large pharmaceutical organisations are known to use IaaS for numerical modelling purposes, due its superior speed to operation (as compared with the lengthy traditional process of procuring and installing physical hardware).
Few enterprises are adopting IaaS for mission-critical production services at this time. There are a number of reasons for this, with security being one of the dominant factors. Other factors include:
- It is usually 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 often be more cheaply managed on...
