Objeto contractual, modificaciones al contrato inicial, etapas y plazos de ejecución

When addressing the challenge of location inhomogeneity in clouds (cf. Def.4.6) with respect to location determination in OpenStack, it is necessary to extend (1) resource management to include the ability to decide and enforce the location of virtual resource placement and (2) the logging mechanisms to provide all information necessary for compliance monitoring and reporting. This extension is called theLocation-Determining resource management and logging Architecture (LDA), and is presented in the following.

The implementation work presented in this thesis was developed between 2012 and 014 with the support of several bachelor’s and master’s theses [19] [118] [23] [58], which were (co-)supervised by the author of this thesis.

In parallel to this thesis, the concept of geo-tagging using trusted computing pools was developed in OpenStack by the Intel Corporation and demonstrated first on 11 April 2013 at the Forum of the National Cybersecurity Center of Excellence (NCCoE) [217]. The concept of geo-tagging is based on the draft on Trusted Geolocation in the Cloud: Proof of Concept Implementation developed by theNIST since December 2012 [17]. Correspondingly, there exists an OpenStack blueprint on geo-tagging1which was created2 on the 25th of September 2013 and proposes generally the same code intervention points in OpenStack Compute Nova and OpenStack Dashboard Horizon as were chosen in this thesis. The implementation of the OpenStack blue-print is not publicly available and not yet included in any released version of

1_{The OpenStack blue-print on geo-tagging can be found in the OpenStack Wiki athttps://wiki.openstack.} org/wiki/GeoTagging(last visited: 30.06.2015).

2_{According to the page information of the OpenStack wiki the blueprint was created on 09:29, 25. Sep. 2013 (in} the OpenStack Wikihttps://wiki.openstack.org/w/index.php?title=GeoTagging&action=info; last visted: 30.06.2015).

OpenStack.1Therefore, a comparison with the implementation work presented in this thesis is limited to the OpenStack blueprint and the correlated demonstration of the Trusted Geolocation in the Cloud: Proof of Concept Implementation[217].

TheLDApresented in this thesis has been implemented independently of any work done on the concept of geo-tagging. Consequently, both implementations are individual pieces of work with their own contribution to a proof of concept for trusted location determination in clouds. In particular, the model for information flow control presented in Section5.3marks a major difference between the two implementations since these methods for information flow control are neither included nor considered in the concept of geo-tagging. Another major difference between the two implementations is that LDA is based on OpenStack Compute cells while the approach on geo-tagging uses trusted computing pools2 which are based on Intel’sTrusted Execution Technology (TXT)technology for implementingTPMsupport and is therefore limited to hardware resources providing TXT support (i.e., using Intel-CPUs). This restriction to a specific hardware vendor (i.e., the Intel Corporation) limits the general applicability to hardware resources of other hardware vendors. The LDA is not limited to hardware resources of a specific hardware provider and can be applied generally.

To implement theLDA, the resource management, logging mechanisms, and the dashboard has been extended by (1) location-determined resource management, (2) location determined logging, and (3) compliance reporting. Figure 6.1 illustrates the components modified and added here as well as additional control flow and logging data flow. Examples of configu- ration, execution, and logging are presented in the context of the experimental evaluation in Section6.1.3.

The implementation of location-determined resource management consists of (i) adding location parametersto the configuration of virtual machines in the DASHBOARD, (ii) extend- ing the NOVAAPI and NOVADATABASE to process the added location parameters, (iii) im- plementing anXML-based location policy determining virtual machine placement with respect to location parameters, and (iv) implementing a location filter in the NOVA SCHEDULERen- forcing the location policy [19]. The location parameters for virtual machine configuration are data type (i.e., category of processed data) and origin (i.e., origin of processor, controller, and data subjects or ‘data owner’) which are required for deciding on the necessary level of protection (cf. Section3.6.1and Def. 4.6). In addition, an option for creating a back-up in- stance of a virtual machine is provided. When selected, two virtual machines are created, one productive virtual machine and one back-up instance. The location policy contains rules which return applicable cells in OpenStack based on data type and origin. AnXML Schema Defini- tion (XSD)forXML-based location policies and the example polices used in the experimental evaluation can be found in AppendixC. Assuming that each cell is located in a single specified and known country, the rules of the location policy enables the resource scheduler to decide on the target location of virtual resources based on the parameters, data type and origin, specified by the corporate customers. Further, a dedicated set of rules for allocating hardware resources for back-up instances is specified which is used when creating back-up instances. The location

1_{Last time verified on 30.06.2015.}

2_{The OpenStack blueprint on trusted computing pools can be found in the OpenStack Wiki on the Internet:https:} //wiki.openstack.org/wiki/TrustedComputingPools(last visited: 30.06.2015).

filter at the NOVASCHEDULER filters the available cells in OpenStack based on the location parameters and the applicable rules of the location policy. For each requested virtual machine, logs of the applied rules and filtered cells are written at the Nova Server locally. The filtered list of available cells is then forward to the API CELLwhere a cell is selected from this filtered list according to the original resource allocation process in OpenStack. Then, the requested virtual resource is created on a hardware resource selected by the cell locally. Consequently, the location filter does not affect the resource allocation in OpenStack but reduces the search space of the resource allocation algorithm to those hardware resources that are in compliance with the location parameters (i.e., hardware resources of cells that are located in countries with an adequate level of protection). In the case of allocating hardware resources for a virtual machine with back-up instance, the location filter applies the location policy for the virtual machine and its back-up instance individually. In particular, it is possible to schedule virtual machines and back-up instances on disjunct sets of cells, thereby enforcing their hosting on hardware resources of separated cells.

The implementation of location-determined logging consists of (i) the extension of the CEILOMETERAGENTCOMPUTEby a plug-in that gathers the logging data of the hypervisors and (ii) extending the CEILOMETERCOLLECTOR, CEILOMETERDATABASE, and CEILOME- TERAPI to also process hypervisor logs [118]. The hypervisor logs are accessed via theVMI

libvirt (cf. ‘LibvirtAPI’ in OpenStack documenation [157] and libvirt documenation [167]). By using the LIBVIRTAPI of OpenStack, logs are gathered independently of the used hypervi- sor, and therefore, logging is supported for a large number of hypervisors.1 The authenticity and integrity of logging are addressed by using a public-private key signature scheme with an individual private key for each compute node for signing logging data and a corresponding public key for verifying the integrity and authenticity of the logging data [58].

For the purpose of compliance reporting, two new components were added to the Horizon Server: (i) the COMPLIANCECHECKERevaluating the logging data of the Ceilometer Server and the Nova Server and (ii) the AUDITBOARDvisualising compliance reports on evaluation results [23]. Detected compliance breaches are wrong placements of virtual machines with respect to the location policy and location parameters and deviations in the virtual machine execution from the requested configuration (e.g., CPU, memory, and storage). For logging evaluation, the logging data provided by the CEILOMETER API is compared with the local logs of the NOVASCHEDULER and the location policy stored at the Nova Server. The com- pliance reports are visualised via the AUDIT BOARDwhich is implemented as a plug-in of the DASHBOARD. There are three different views of the compliance reports: (1) the cloud customer’s view, (2) the cloud provider’s view, and (3) the view for authorised third parties. The views are implemented according to the monitoring and reporting architecture proposed in Section5.4.3. Consequently, the cloud customer’s view reports on virtual resources of the respective cloud customer only. The cloud provider’s view reports on all hardware resources and virtual resources. The view for authorised third parties is implemented for two use cases with different information levels: (a) an investigation by a tax officer and (b) service operations controls by an external auditor instructed by a cloud customer. The information level pre-

1_{An overview of hypervisors supported by libvirt can be found in the Internet:http://libvirt.org/drivers.} html(last visited: 30.06.2015).

sented to a tax officer is limited to location information of virtual resources of the investigated cloud customer, while the external auditor has the same information level as the instructing cloud customer. Access to the different views is controlled via the access control mechanism of OpenStack. The cloud customer’s view is accessible only by user accounts and the cloud provider’s view only by admin accounts. For the views of authorised third parties, two addi- tional roles are added to OpenStack: (a) tax officer and (b) auditor. Fo each role, access to the audit board is restricted to information appropriate to that role.

6.1.3 Experimental set-up and evaluation results

The experimental set-up is based on four physical servers which are virtualised using VMWARE ESXi in Version 5.1.0. All components of OpenStack are installed on virtual servers running Ubuntu 13.10. OpenStack is installed in release version 2013.2.3, ‘Havana’. The only excep- tion is the OpenStack Telemetry Ceilometer, which is installed in OpenStack release version 2014.1, ‘Icehouse’. The version of the messaging bus RabbitMQ is 3.1.3.

Figure6.2illustrates the experimental set-up of virtual servers and virtual networks. In to- tal, there are 20 virtual servers. Seven virtual servers are hosting the management components including OpenStack Compute Nova, OpenStack Dashboard Horizon, and OpenStack Teleme- try Ceilometer, which is modified as described in Section6.1.2. Further, there are 13 virtual servers organised in five OpenStack Compute Cells simulating a globally distributed cloud in- frastructure. The simulated locations are Germany (DE Cell), France (FR Cell), Switzerland (CH Cell), the United Kingdom (UK Cell), and Singapore (SG Cell). Each cell is configured to operate in a dedicated VLAN and consists of a control node and either one or two com- pute nodes which is shown in Figure 6.2. The compute nodes use QEMU version 1.5.0 for the nested virtualisation of virtual machines. The nested virtualisation is controlled via libvirt using version 1.1.1. The CEILOMETER AGENT COMPUTEat the COMPUTENODESis con- figured to log and forward the state of the hypervisor every ten minutes, which is the default setting of OpenStack Telemetry Ceilometer.

Figure 6.2: Experimental configuration of virtual servers and virtual networks.

CH Cell DE Cell SG Cell UK Cell FR Cell VLAN 111

DE Control Node DE Compute Node 1 DE Compute Node 2

VLAN 2

Nova Server MySQL & RabbitMQ Ceilometer

VLAN 112

FR Control Node FR Compute Node 1 FR Compute Node 2

VLAN 113

UK Control Node UK Compute Node 1

VLAN 230

SG Control Node SG Compute Node 1

VLAN 121

CH Control Node CH Compute Node 1 CH Compute Node 2

Horizon Server Keystone Server Glance Server Cinder Server

Switch

Virtual Server

Virtual LAN

virtual machine placement as well as the logging and reporting mechanisms of theLDA are demonstrated. For that purpose, a set of eight location classeslocSC, which are illustrated in

Figure6.3, are defined according to Definition5.42. Hardware resources of each cell are as- signed the location class of the corresponding country, e.g., DE COMPUTENODE1 is assigned

loc_SC

DE∈locSC. Based onlocSC, a location policy is defined covering rules for two data types

(i.e., personal data and financial data) and six origins (i.e., Germany, France, United King- dom, Switzerland, Singapore, andEU/EEA). The rules of the location policy are illustrated in Figure6.4. For each data type and data origin, a set of allowed cells Celluseris defined. Addi-

tionally, there is defined a set of cells Cellbakfor hosting back-up instances.1 When requesting

a virtual machine with a dedicated back-up instance, the location filter of the NOVASCHED- ULERallocates the virtual machine at Celluser\Cellbak and the back-up instance at Cellbak and

if Celluser = Cellbak both instances are located at the same cell, i.e., Celluser. For example,

when requesting a virtual machine for processing personal data originating from Germany, the virtual machine is located atlocSCEU\locSCU K= {locSCDE,locSCFR,locSCU K}\locSCU K=

{loc_SC

DE,locSCFR} and the back-up instance is located atlocSCU K(cf. Figure6.4).

Figure 6.3: Location classeslocSC in the ex- periment. Global SG EU DE FR Local CH UK

Figure 6.4: Location policy in the experiment.

EU DE FR UK CH SG Data o rigin

Personal data Financial data

EU UK DE, FR FR EU DE EU DE CH CH SG SG

Celluser Cellbak Celluser Cellbak

EU FR DE DE FR FR UK UK CH CH SG SG Data type

The experiment consists of requesting four virtual machines with different configurations for data type, data origin and back-up option. All logging data of the experiment and sample screen shots of the modified DASHBOARD and AUDIT BOARD can be found in AppendixD. Table6.1lists the configuration of the virtual machines, the result of the decision by the loca- tion policy and the allocated compute nodes. First, three virtual machines configured to host financial data of different origins are requested, one after another. The rules on financial data are very restrictive (cf. Figure6.4) and only allow the allocation of hardware resources that are located in the cell corresponding to the country of data origin. In the experiment, the compute nodes are selected accordingly to the decision by location policy. If the back-up option is se- lected the virtual machine and the back-up instance are distributed over both compute nodes of each selected cell. This implies that load balancing is active. Then, the forth virtual ma- chine is configured to host personal data originating from theEU/EEA. In this case, the most relaxed rule applies since the location policy allows the allocation of any cell located within theEU/EEA. The dedicated cell for back-up instances is located in United Kingdom. The se- lected compute node for the virtual machine is DE COMPUTE2 and for the back-up instance, UK COMPUTE1. This is in compliance with the decision with respect to the location policy.

1_Cell

Additionally, the resource allocation of the forth virtual machine illustrates the compliant op- eration of the location filter in several ways. First, compute nodes located within theEU/EEA

are selected albeit there are unused compute nodes in the CH Cell (i.e., CH COMPUTENODE 1) and SG Cell (i.e., SG COMPUTE NODE1). This is in compliance with the location policy where CH Cell and SG Cell are not allowed for personal data originating from theEU/EEA. This implies that the decision with respect to the location policy outweighs load balancing. A second observation is that even within the cells located in the EU/EEA the virtual machine is placed on the already used compute node, DE COMPUTE 2, instead of being placed on the unused compute node, UK COMPUTE 1. Again, this is in compliance with the location policy according to which the UK Cell is reserved for back-up instances, and is therefore not available for the placement of the virtual machine itself. This implies that the decision by the location policy also outweighs load-balancing with respect to the disjointed placement of back-up instances. Finally, it is observed that the back-up instance is placed on compute node

UK COMPUTE 1, which complies with the location policy. Screenshots of the DASHBOARD

showing the extended virtual machine configuration, the overview on running compute nodes, and the overview on virtual machine instances can be found in AppendixD.3.

Table 6.1: Virtual machine configuration with resulting decisions and resource allocation

Virtual machine configuration Decision by location policy Selected compute node

No. Data type Data origin Back-up Celluser Cellbak Virtual machine Back-up instance

1 Financial data Germany yes DE DE DE COMPUTE2 DE COMPUTE1

2 Financial data Switzerland no CH CH CH COMPUTE2 —

3 Financial data France yes FR FR FR COMPUTE2 FR COMPUTE1

4 Personal data EU/EEA yes EU UK DE COMPUTE2 UK COMPUTE1

Observations in the experiment are logging data of the hypervisors collected by the Ceilo- menter Serverand logging data of the applied rules and filtered cells collected by the Nova Server. All logging data can be found in the Appendix D.1and AppendixD.2. The structure and information content of the logs are exemplified by the request of the virtual machine no. 4.

Listing 6.1: Nova Server log-file of virtual ma- chine no. 4. 1 [d a t a] 2 t y p e = " p e r s o n a l " 3 o r i g i n = " eu " 4 t i m e s t a m p = " 2014−11−27 1 2 : 3 2 : 1 5 UTC" 5 [a c c e p t e d] 6 f r = t r u e 7 de = t r u e 8 s g = f a l s e 9 ch = f a l s e 10 uk = f a l s e 11 a p i = f a l s e

ID in OpenStack and file name: 1ADAFF73-6741-422B-B2F0-7C0E1A2459BD

Listing 6.2: Nova Server log-file of back-up instance of virtual machine no. 4.

1 [d a t a] 2 t y p e = " p e r s o n a l " 3 o r i g i n = " eu " 4 t i m e s t a m p = " 2014−11−27 1 2 : 3 2 : 1 6 UTC" 5 [a c c e p t e d] 6 uk = t r u e 7 s g = f a l s e 8 f r = f a l s e 9 ch = f a l s e 10 de = f a l s e 11 a p i = f a l s e

ID in OpenStack and file name: 6EDED12F-B120-4FC6-8C21-DAA4084630A0

Listing 6.1and Listing6.2 list the log-files recorded at the Nova Server. Each log-file is associated by file name with the virtual machine’s ID in OpenStack. Further, each log-file contains the location parameter TYPE (i.e., data type) andORIGIN (i.e., data origin) that the

Listing 6.3: Excerpt of ceilometer log for DE COMPUTE2 before requesting virtual machine no. 4. 1 ( 2 . . . 3 [ t i m e s t a m p ] => 2014−11−27T12 : 2 7 : 2 8 4 . . . 5 [ r e s o u r c e _ m e t a d a t a ] => A r r a y 6 ( 7 . . . 8 [ c e l l ] => de 9 [ c o m p u t e _ n o d e ] => DeCompute2 10 . . . 11 [ i n s t a n c e s . 0 ] => 12 4 b 5 9 2 9 5 f −56a9 −4126−8c07 −4 f f 0 e 7 9 3 f 9 1 9 13 [ i n s t a n c e s . amount ] => 1 14 . . . 15 ) 16 . . . 17 )

Listing 6.4: Excerpt of ceilometer log for DE COMPUTE2 after requesting virtual machine no. 4. 1 ( 2 . . . 3 [ t i m e s t a m p ] => 2014−11−27T12 : 3 7 : 2 8 4 . . . 5 [ r e s o u r c e _ m e t a d a t a ] => A r r a y 6 ( 7 . . . 8 [ c e l l ] => de 9 [ c o m p u t e _ n o d e ] => DeCompute2 10 . . . 11 [ i n s t a n c e s . 0 ] => 4 b 5 9 2 9 5 f −56a9 −4126−8c07 −4 f f 0 e 7 9 3 f 9 1 9 12 [ i n s t a n c e s . 1 ] => 1 a d a f f 7 3 −6741 −422b−b2f0 −7c 0 e 1 a 2 4 5 9 b d 13 [ i n s t a n c e s . amount ] => 2 14 . . . 15 ) 16 . . . 17 )

decision is based on and the timestamp of the decision. In addition, the result of the decision is listed for each available cell whereTRUEindicates that the cell is accepted andFALSEthat the cell was rejected. The logged decisions comply with the applicable rule of the location policy (cf. Figure6.4). In addition, the timestamps imply that the decision on the placement of the virtual machine was made before that on the placement of the back-up instance. Listing6.3

and Listing6.4show an expert ceilometer log for DE COMPUTE2 before and after the virtual machine no. 4 is requested (cf. ListingD.18 and Listing D.19for the complete log). In the listings, selected key-value-pairs of theJSON-object used by OpenStack Telemetry Ceilometer for representation are shown with respect to relevance for validating the placement of virtual machine no. 4. Each ceilometer logging entry particularly provides the timestamp of creation and information on hosting cell and compute node as well as the hosted instances by number and ID. The first excerpt is created before the request and indicates that there is only a single virtual machine running on DE COMPUTE2. Then, after the request, the second excerpt of the log indicates that there is an additional virtual machine running which has the ID of the