The SECCRIT10 consortium has developed an architectural framework for deploying infrastructure services in the cloud, which provides a basis for the development of research presented in this thesis (ADaaS - see Chapter 6). An architectural framework is needed in order to identify and locate the var- ious mechanisms and potential new interfaces that are necessary to support infrastructure IT services.
The architectural framework was derived by SECCRIT consortium and has four abstraction levels. The key aspects of these levels are discussed using several viewpoints which include: multi-tenant, network access, monitoring, policy, legal and resilience. The author’s contribution to the architectural framework is the resilience part which is highlighted in Section 2.3.1 and il- lustrated in Figure. 2.6. The resilience viewpoint is realized using tools and ideas developed as part of this thesis. These include the real time anomaly detection technique, the resilience management framework and anomaly de- tection as a service. 8 https://www.ogf.org/ogf/doku.php 9https://www.cloudindustryforum.org/ 10 www.seccrit.eu
Chapter 2. Background and Related Work 16 The proposed architectural as shown in Figure.2.3 aims at a more pre- cise role distinction that allows for better security analysis, separation of responsibilities and identification of separate administrative interfaces. It is an architectural framework, because it mainly serves descriptive and explana- tory purposes, rather than specification purposes like a reference architecture definition in a standards organisation.
Tenant Infrastructure Level Physical Cloud Infrastructure Level CI Service Critical Infrastructure (CI) Service Level Component A Abstraction Level CI Service User Resources CI Service Provider Tenant Infrastr. Provider Service Components Tenant Infrastructure
Cloud Infrastructure (Data Centre)
Cloud Infrastructure Provider Client Devices Stakeholder Provides Service (SaaS /Paas) Provides Virtual Infrastructure (IaaS /PaaS) Provides Virtual Resources (IaaS)
•Virtual Compute Resources
•Virtual Storage •Virtual Network manages cloud resources manages virtual resources manages service resources •Compute •Storage •Network Component B Component C User Level SLAs
Figure 2.3: SECCRIT architectural framework [122]
Therefore, one should be able to map existing specific cloud architectures, deployments, and usage scenarios partially or fully to the SECCRIT architec- tural framework. An important aspect within the cloud services context is to consider that a single cloud infrastructure is typically simultaneously used by several tenants (i.e., customers, users of the cloud infrastructure provider), whose virtual resources are usually isolated from each other to some degree within the Cloud Infrastructure. The distinction between the virtual ten- ant infrastructure and the physical cloud infrastructure is important, since a clear separation between responsibilities is necessary. In case a service fails due to some anomaly, a root cause analysis should reveal the responsible party. Moreover, additional monitoring or logging mechanisms for anomaly detection can be located within the cloud infrastructure, as well as within the virtual infrastructure of the tenant. In this context, it may be helpful to identify additional interfaces that allow for increasing the trust level be- tween the tenant and the cloud infrastructure provider by permitting some level of detection as a service. Furthermore, the architecture must clearly
distinguish the service provider from the virtual tenant infrastructure. This allows to separate two important aspects of any service hosted in cloud: func- tional and behavioural features. On the service layer, the functional features of the service are dealt with. Which components are required to compose the service and how these components need to be inter-connected. On the tenant infrastructure level the behavioural features of the service are dealt with: this includes elasticity features, component redundancy, and overload control. Failures on the physical infrastructure level can be made opaque to the service by self-healing mechanisms on the tenant infrastructure level, e.g., automatic fail-over to redundant components and auto-recovery by on- demand provisioning of virtual resources. In addition, geo-diversity can be realized on the tenant infrastructure level by requesting resources from mul- tiple independent cloud infrastructure providers for increased dependability but also for higher security and resileince requirements [122].
SECCRIT architecture divides activities in a cloud environment into four different levels of abstraction. The different abstraction levels correspond to different stakeholders and their view on the managed resources.
User level – service user who remotely accesses the infrastructure ser- vice. For instance, an urban traffic management operator could observe and control the traffic flow within a city, using web-based interfaces as well as various distributed sensors that deliver measurement data as input to the next lower service level components.
Infrastructure service level – this level is controlled by the service provider who manages the resources at the service level. The service is com- posed of several components that interact with each other in order to provide the actual service. The service provider monitors the service operation and performance at this level. The service components usually either provide the application or the platform that are required at the user level. The service components are instantiated on the virtual infrastructure that is provided by the next lower level.
Tenant infrastructure level – provides a virtual infrastructure that consists of virtual compute resources, virtual storage, and virtual network resources. The virtual infrastructure is managed by the tenant infrastructure provider. This distinction of tenant from service provider is needed since they may be separate organisations. Several of such tenants are typically hosted within one cloud infrastructure that is the next lower level. The tenant infras- tructure provider may provide either the pure virtual infrastructure (IaaS) or some basic services as a platform (PaaS) to the service provider. In the for- mer case, the CI Service Provider may install complete VM images containing an operating system, middleware services, and application-oriented service components, including necessary configuration data. In the latter case, the tenant infrastructure provider may provide and operate some pre-installed
Chapter 2. Background and Related Work 18 operating system images and middleware or supporting services.
Physical cloud infrastructure level– provides real physical compute, storage, and network resources, which are hosted in a data centre and ad- ministered by the cloud infrastructure provider. This level usually provides virtual resources (IaaS) to its upper level, i.e., the tenant. The virtualiza- tion solution usually provides (a certain degree of) isolation between the different tenants that are mapped onto the same physical infrastructure and thus permits the sharing of resources. For increasing the resource efficiency, the cloud infrastructure provider can usually transparently move virtual re- sources across its physical infrastructure.