Page 854 - Cloud computing: From paradigm to operation

5 Intercloud and interoperability

5 Conventions

In this Recommendation:
The keywords ''is required to'' indicate a requirement which must be strictly followed and from which no
deviation is permitted if conformance to this document is to be claimed.
The keywords ''is recommended'' indicate a requirement which is recommended but which is not absolutely
required. Thus, this requirement need not be present to claim conformance.

6 Overview of inter-cloud trust management
The inter-cloud computing concept is based on the relationship (pattern) among multiple cloud service
providers (CSPs). This pattern (peering, federation or intermediary) allows a CSP to interwork with one or
more peer CSPs to assure intermediation and security of services provided by these CSPs. The trusted inter-
cloud relationship among multiple CSPs relies on confidence between CSPs, or between a cloud service
customer (CSC) and a CSP, as one of them has to delegate physical control over applications, services,
resources and data to the others. Therefore, trust management is a key point between CSPs, or between a
CSC and a CSP in inter-cloud.

The trust management of inter-cloud uses a two-dimensional (vertical and horizontal) model, where the
vertical axis is based on the layers of the cloud computing reference architecture [ITU-T Y.3502], and the
horizontal ones is based on the interconnection of CSPs based on the inter-cloud framework [ITU-T Y.3511].

The inter-cloud trust management framework relies on components for managing isolation and security
mechanisms, which handle cross-layer trust and establish chain of trust, respectively [ITU-T Y.3514].
According to particular needs, inter-cloud trust management may either be CSC-related or CSP-related.
From a CSC-related perspective, major threats concern data security and privacy. Even assuming a trusted
cloud service provider, a malicious administrator has sufficient permissions to affect unauthorised use and
to modify customer information. Thus, CSP control over the infrastructure should be limited to avoid
inspection or analysis of user data and virtual machine (VM) instances without explicit CSC consent.
Moreover, security should be self-service, so that a CSC can exercise fine-grained control over protection of
their cloud resources according to a given security service level agreement (SLA). This means the CSC should
be able to actively monitor its allocated resources, while enabling a high level of customizability of the
architecture and its services.

From a CSP-related perspective, major threats are malicious customers issuing attacks against the
virtualization layer, to break isolation or perform denial-of-service (DoS). An attacker is a non-privileged
malicious cloud tenant. Mitigation of such threats implies first isolation: tenants should not be authorized to
monitor or modify VM state or data from other tenants. It also means a small trusted computing base: the
number of vulnerabilities and failures in the platform is directly linked with the code size run at the highest
privilege level and the set of primitives exported.
Many different classes of mechanisms and architectures have been proposed to address this issue, where
trust management and isolation are intimately linked. Representative isolation architectures include modular
hypervisors partly controlled by the CSC or secure enclaves based on hardware security mechanisms. Side-
channel attacks also introduce major isolation issues for inter-cloud systems. Although many cryptographic
solutions protect user confidentiality in the cloud, it is not possible to perform efficient and fast enough
arbitrary computations on the data while they are encrypted.
In an inter-cloud environment, reputation is a key factor for selecting the CSP to transact with. There are
different approaches to implement reputation-based trust management in inter-cloud environments, all of
them are based on a uniform cloud SLA framework which could make CSP and CSC avoid confusion and have
a common understanding about the cloud service quality commitment.

846