**7.1 Motivating scenario**

*Cloud Computing Security - Concepts and Practice*

**Category Checklist**

*Security checklist for evaluating the framework.*

Selection of a suitable architectural pattern

Analysis of the

Optimisation of the deployment of the cloudhosted services

Evaluation of the required degree of isolation between tenants

deployment requirements of the cloud-hosted

varying degrees of tenant isolation are possible. Therefore, it is important for software architects to be able to able to control the required degree of isolation between

What are classes of cloud patterns available, what are the tools and processes

What are the data and processes of the cloud-hosted service that require security? What is the required degree of isolation between tenants accessing

How can you map the key resources of the cloud-service (e.g., store for the archive data) to the cloud provider's platform? What are the trade-offs to consider when securing the deployment of cloud-hosted services? (e.g.,

What are the components (or tenants) that are required to design (or integrate) with the cloud-hosted services? How feasible is it to tag components

to support the selection of suitable cloud patterns.

the components of the cloud-hosted services?

customizability, scope of control, business requirements)

For instance, the deployment of an application component specifically for one tenant will achieve a high degree of isolation. This would make sure that when workload changes, there is little or no performance impact between the

However, because components are not shared it implies duplicating the components for each tenant, which leads to high resource consumption and running cost. Overall, this will limit the number of requests allowed to access the components. A low degree of isolation would allow sharing of the component's functionality, data and resources. This would reduce resource consumption and running cost, but the performance of other components may be affected when one of experiences a

This is a decision-making challenge that requires an appropriate decision to be made to address the trade-off between a lower degree of isolation versus the possible influence that can occur between components or a high degree of isolation versus the difficulty of high resource usage and component running costs.

In a nutshell, the procedure for implementing the framework can be summaries with following four steps: (i) Select suitable deployment patterns (one or combination of several patterns), (ii) Evaluate the effect of varying degrees of isolation on the cloud-hosted service, (iii) Analyse the deployment requirements of cloudhosted services and (iv) optimise the deployment of the cloud-hosted service to

**6.2 Developing a security checklist for deployment of cloud-hosted services**

In addition to the framework, CLAMP, we develop a security checklist to guide software architects in securing the deployment of cloud hosted services. The layers of the frameworks are used to develop the categories of the checklist. Many of the items in the checklist may seem obvious but the purpose of a checklist is help ensure the completeness of the security design while implementing the CLAMP

In using the security checklist, the software architect should think about how to review the security of the cloud-hosted services and figure out how well it satisfies security in each of the categories of the framework. In other words, what questions

tenants sharing components of a cloud-hosted application.

or whole system?

**88**

framework.

components.

**Table 1.**

change in workload.

guarantee multitenancy isolation.

Let us assume that there are multiple components of a cloud service (e.g., data-handling component) hosted on the same or different cloud infrastructure. These components which are of various types and sizes are required to design (or integrate with) a cloud-hosted service (e.g., continuous integration system such as Hudson or Jenkins) and their supporting processes for deployment to multiple tenants. Tenants, in this case, may be multiple users, departments of a company or different companies. The laws and regulations of the company make it liable to share and archive data generated from the component (e.g., builds of source code) and keep it accessible for auditing purposes. However, access to some components or some aspects of the archived data will be provided solely to particular groups of tenants for security reasons. The question is: in a resource-constrained environment, how can we secure the deployment of components of this cloud-hosted service in a way that guarantees the required degree of isolation between other tenants when one of the tenants (or components) experiences a high workload or security breach (**Table 2**).
