2. Consideraciones sobre el fondo del asunto
7.2. ASUNCIÓN DE RIESGOS PREVISIBLES
Based on the implementation work, the experiment, and general considerations, there are mul- tiple observations made with respect to the impact of legally compliance cloud computing on cloud characteristics [141] [211], i.e., (1) resource pooling/virtualisation, (2) rapid elasticity/s- calability, (3) on-demand self-service/pay-per use utility model, (4) measured service, and (5) broad network access (cf. Section2.1.1), which are discussed in the following.
The impact on resource pooling/virtualisation is not considerable, since resource pool- ing and virtualisation are rather prerequisites than restrictions. When classifying hardware and virtual resources by location, it is still possible to organise resources by using virtualisation techniques and pooling them for provisioning. For legal compliance, it is sufficient that each resource pool can be classified correctly by location and effective level of security. For this purpose, resource allocation has to be made accordingly to the information flow allowed be- tween the security class of the resource pool and security class of the assigned virtual resource. Usually, the clouds are organised in subsets of resource pools which are each operated by an 1This can be achieved by locking the virtual resources of searched corporate customer in place by changing their security classification to enforce the current placement, which can be the first step to initiate what is called a quick-freeze (cf. Section3.5.2).
individual hosting site (cf. global clusters and local clusters in Section4.1.4). Therefore, the security class of each resource pool is determined by the location of its operating hosting site and itseffective level of security. Even if a resource pool is operated by multiple hosting sites, the security classes can be determined correctly by the least upper bound of the security classes of the involved hosting sites, i.e., by applying the⊗-operator (cf. Section5.3.1). Further, it is possible to cover differences in theeffective level of securityof individual hardware resources. In such a case, hardware resources of the same security class are pooled. Then, each resource pool consists of homogeneously classified hardware resources and is classified accordingly. In theLDA, resources are pooled by using OpenStack Compute Cells and virtualisation is per- formed by compute nodes. The management of cells is very flexible and compute nodes can be added and removed during run-time (cf. ‘cells’ in OpenStack documenation [157]). Since the
LDAis based upon OpenStack Compute Cells, the resource pooling/virtualisation characteris- tic is a prerequisite for location determination and is not restricted by its implementation.
The impact on rapid elasticity/scalability can be considerable since security constraints can limit the hardware resources that are available for virtual resource allocation. Only hard- ware resources with sufficient security classes can be assigned if virtual resources require a specific location and theensured level of security. If hardware resources with sufficient security classification are not available, additional virtual resources either cannot be created (reject) or have to be assigned to hardware resources with insufficient security classification (SLAbreach). Alternatively, reorganising the embedding of virtual resources can help the offort to find a more efficient embedding, freeing hardware resources with sufficient security classification through reduction of over-provisioning (cf. evaluating embeddings in Section5.4.2). Further, it is also possible to degrade the security classification of virtual machines to security classes where hardware resources are available. Which strategy is used (i.e., rejection,SLAbreach, reorgan- isation, or degradation) usually depends on the contractual agreement between cloud provider and corporate customer. A common practice of cloud providers is to accept theSLAbreach and refund the corporate customers for the degraded services (e.g., amazon’s EC2 service level agreementson availability1). However, there are cases where service degradation and SLA
breaches are not acceptable. For example, without explicit permission of the responsible tax office, it is forbidden to process data that are relevant to German tax law abroad (cf. Sec- tion3.5.3.2). Here, a degradation orSLAbreach can result in administration fees (e.g., BDSG §43, 44 and StGB §204) and custodial sentences (e.g., BDSG §44 and StGB §203, 204). There- fore, reorganisation and rejection are better strategies with respect to legal certainty than service degradation and acceptedSLAbreaches. In addition, it is possible to increase the number of hardware resources of the specific security classification to better fit the corporate customers’ demands.
When applying metrics to evaluate the quality of the embedding (cf. Section 5.4.2), it is possible to determine the degree of over- and under-provisioning. This empowers the cloud provider to consider the legal and technical consequences when scheduling virtual resources. Therefore, rapid elasticity and scalability may be reduced when it is necessary to enforce le-
1Amazon charges their cloud customers for a 99.95% availability and refunds gradually when lower availability is provided; cf. EC2 service level agreements in the Internet: http://aws.amazon.com/de/ec2/sla/(Last visited: 30.06.2015).
gal compliance, due to a shortage of hardware resources with sufficient security classification. However, cloud computing remains rapid, elastic and scalable if hardware resources with suffi- cient security classification are available. The proof-of-concept implementation shows that the virtual machine configuration can be extended by security parameters, which allows automated decision-making and enforcement of resource allocation (cf. Section6.1.3). The impact on run- time behaviour is not the focus of this thesis and, is therefore not investigated in the experiment. In any case, the impact can be estimated analytically. Each included security parameter (i.e., location, confidentiality, integrity, and availability) introduces an additional dimension to the NP-hard decision problem of virtual resource allocation (cf. Section5.4.2). The complexity of existing algorithms solving this class of decision problems in general scales with the num- ber of dimensions on a square-logarithmic base (vector scheduling), logarithmic base (vector bin packing), and linear base (knapsack problem) [39]. This is also observable for resource allocation algorithms for virtualised service hosting platforms and specifically cloud infras- tructures [189]. Therefore, the impact of the additional dimensions on the run-time complexity of resource scheduling algorithms is rather low in comparison to the exponential complexity of finding optimal embedding. Investigations into the proof-of-concept implementation shows that also logging scales on a linear basis with respect to number of log entries generally and with respect to the number of logged compute nodes specifically [118].
The impact on on-demand self-service and pay-per-use utility model is not significant since corporate customers can order virtual resources on-demand with or without security con- straints, which are then processed automatically by the cloud platform. In the proof-of-concept implementation, location constraints are specified by the corporate customer when requesting virtual resources in the DASHBOARD. The virtual resources are then scheduled and provi- sioned automatically, which facilitates the on-demand self-services. Further, the pay-per-use utility model can be directly applied on requested security constraints by charging based on provided security properties. For example, the cloud provider can charge an additional fee for requesting location-determined hosting to compensate the reduced flexibility in virtual resource placement due to location constraints. Therefore, introducing security constraints for legally compliant cloud computing fully complies with the characteristic of on-demand self-service and the pay-per-use utility model.
The impact on measured services is considerable since monitoring and reporting of le- gal compliance requires the measurement of security classifications and extended logging with respect to security properties (cf. Section 5.4.1and Section 5.4.3). In the proof-of-concept implementation, existing logging mechanisms are used and extended to log security relevant information at the hypervisors, and the information is made available for monitoring and report- ing in the DASHBOARD(cf. Section6.1.2). Further, the implemented logging and monitoring architecture is fully automated (cf. Section6.1.2) and scalable (cf. ‘impact on on rapid elastic- ity/scalability’ above). Therefore, the characteristic of measured services is feasible for legally compliant clouds which support scalable and automated service monitoring and reporting.
The impact on broad network access is in principle not significant since virtual resources remain accessible irrespective of the security properties that are applicable. This is because access to virtual resources has no impact on theinformation flow of virtual resourcesbut on theinformation flow of processed datain virtual resources (cf. Section5.1.2). However, the
control of access to virtual resources is relevant with respect to the location and theeffective level of securityat the point of access. For example, according to German data protection law, transmitting personal data to a third country in general is illegitimate if no explicit statutory permission applies, independent of whether these data are processed inside or outside of the cloud. Then again, the control ofinformation flow of processed data– and therefore the ac- cess to virtual resources – is in the responsibility of the corporate customer (cf. Section5.1.2). For that reason, there are no limitations in the broad network access from the cloud providers’ perspective. Nevertheless, if the cloud provider is managing access control to virtual resources on behalf of the corporate customers then the cloud provider has to restrict the broad network access to communications end-points with respect to the end-points’ location and theireffec- tive level of security. Consequently, there is an impact on broad network access with respect to control the information flow of processed data(which is usually handled by the corporate customers) but not with respect to control theinformation flow of virtual resources(which is handled by the cloud providers).