The Necessity of Legally Compliant Data Management in European Cloud Architectures

Transcription

1 The Necessity of Legally Compliant Data Management in European Cloud Architectures Szilvia Varadi a, Attila Kertesz b, and Michael Parkin c a University of Szeged, Department of International and European Law, H-6722 Szeged, Rakoczi ter 1., Hungary varadiszilvia@juris.u-szeged.hu b MTA SZTAKI Computer and Automation Research Institute, H-1518 Budapest, P.O. Box 63, Hungary attila.kertesz@sztaki.hu c European Research Institute in Service Science, Tilburg University, 5000 LE Tilburg, P.O. Box 90153, The Netherlands m.s.parkin@uvt.nl Abstract Taking advantage of flexible resource provisions enabled by Cloud Computing, many businesses have recently migrated their IT applications and data to the Cloud, allowing them to respond to new demands and requests from customers. However, Cloud Computing also moves functions and responsibilities away from local ownership and management to a third-party provided service, and brings with it a set of associated legal issues, such as data protection, licensing, intellectual property rights and the need to comply to necessary regulation. In this paper we evaluate commonly-observed Cloud Computing use cases against the law applying to Cloud Computing to find where legal problems may arise. We derive a general architecture for Clouds and use it to illustrate common Cloud Computing usage patterns. The use cases are assessed against evaluation criteria derived from the relevant Cloud Computing law for the data processing of end-user details and materials, including roles and responsibilities necessary for legal compliance. The Data Protection Directive of the European Union has been used in this evaluation, as it is a commonly accepted and influential directive in the field of data processing legislation. Keywords: European Law; Data Protection; Cloud Computing; Security. 1. Introduction Cloud Computing offers on-demand access to computational, infrastructure and data resources operated from a remote source. Recently, this form of service provision has become hugely popular, with many businesses migrating their IT applications and data to the Cloud to take advantage of the flexible resource provision that can bring benefits to businesses which need to be agile and respond quickly to new demands and requests from customers. As new products and technologies are offered in the near future, Gartner estimates that in the period , $112 billion will be spent by businesses and individuals on Cloud Computing offerings from vendors such as Amazon, IBM, Microsoft and many others (Pring et al., 2010). The technical motivation for Cloud Computing is introduced in (Buyya et al., 2009; Vaquero et al., 2008), but at a working level Cloud solutions provide a business with the option to outsource the operation and management of IT infrastructure and services, allowing the business and its employees to concentrate on their core competencies. This, together with pay as-you-go billing that reduces the need for up-front capital expenditure, means using Cloud Computing solutions allows services to be designed and tailored to the individual requirements of a business. However, Cloud Computing also moves functions and responsibilities away from local ownership and management to a third-party provided service, and brings with it a set of associated legal issues, such as data protection, licensing, intellectual Preprint submitted to CLSR

2 property rights and the need to comply with necessary regulation. As more and more businesses become global in their outlook, concerns also remain over privacy of widely-distributed data and its processing. Regulations focusing on geographical locations may be a large obstacle to a widespread adoption of Cloud Computing solutions by companies (Svantesson and Clarke, 2010). As a result of the pace of technical and economic progress in this field it is therefore important to determine the compliance of commonly-observed Cloud Computing patterns-of-use to legal constraints and requirements. In this paper we provide a method for and the results of an evaluation of commonlyobserved Cloud use cases against the law applying to Cloud Computing. To do this we derive a general architecture for Clouds and use it to illustrate common Cloud Computing usage patterns. To point out where problems may arise, the use cases are assessed against evaluation criteria derived from the relevant Cloud Computing law for the data processing of end-user details and materials, including the roles and responsibilities necessary for legal compliance. To clarify legal compliance in the identified usage patterns, we consider the Data Protection Directive (Directive 95/46/EC, 1995) of the European Union a commonly accepted and influential directive in the field of data processing legislation. This is not the first research carried out in this field, e.g., a paper by Bygrave (Bygrave, 2000) investigates the possible impact of the directive on the activities of E-commerce operators, and later a deliverable of the OPTIMIS project (OPTIMIS, 2010) (which we refer to again in Section 2) studies in detail the applicability of this directive for their own Cloud deployment models. In this paper we take a step forward and examine use cases identified in a generalized architecture compiled from reports of international expert groups and research projects. The remainder of this paper is as follows: Section 2 presents European law applying to Cloud Computing concentrating on data processing legislation, and introduces the relevant roles and the evaluation criteria derived from the data-processing legislation for common Cloud Computing use cases; Section 3 describes and analyzes several Cloud architectures and derive a general Cloud architecture that encompasses their features. Section 4 uses specific use cases of the general Cloud architecture to show where legal questions may arise, and Section 5 discusses the recent European reform and future developments in this area. Finally, the findings are summarized in Section Legislation applying to the Cloud As described in the introduction, Cloud Computing allows the outsourcing of computational power, data storage and other capabilities to a remote third-party. In the supply of any goods and services, the law gives certain rights that protect the consumer and provider, which also applies for Cloud Computing: it is subject to legal requirements and constraints to ensure Cloud services are accurately described and provided to customers with guarantees on quality and fitness-for-purpose. As Section 2 of (OPTIMIS, 2010) describes, the characteristics of Cloud Computing make it of interest to three main fields of law: Intellectual property law, as data and applications (i.e., code) hosted in the Cloud may contain trade secrets or be subject to copyright and/or patent protection; Green (i.e., ecological) legislation, since the datacenters hosting the basic Cloud infrastructure (e.g., servers, switches, routers, etc.) require a large amount of energy to operate and indirectly produce carbon dioxide; Data protection law. In this evaluation of Cloud architectures against legal requirements we have chosen to perform the evaluation exclusively using requirements from data protection law. We do not consider intellectual property law because, as (OPTIMIS, 2010) describes, it is often considered on a case-by-case basis making it difficult to derive common requirements to fulfill these obligations for a Cloud architectures. Secondly, green legislation is also not considered here as compliance to it is an orthogonal concern to the Cloud architecture used; different providers may implement the same architecture with different levels of eco-friendliness. However, using only one field of law does not restrict the evaluation; data protection covers the dynamic provisioning and processing of data in Cloud environments intrinsic to the operation of all

3 Clouds and the field covers the majority of currently available Cloud Computing characteristics and functions, including cases where (Section 4 of OPTIMIS, 2010): The infrastructure used to store and process a costumer's data is shared with other customers (i.e., multi-tenancy); The Cloud provider's servers are located in several jurisdictions; Data is transferred from one location (also called as establishment) to another depending on where resources are available; The Cloud service provider decides the location of the data, service and security standards instead of the customer; IT resources are not dedicated to a customer but instead are dynamically provisioned. Thus, data protection legislation is fundamental to Cloud Computing as the consumer loses a degree of control over personal artifacts when they are submitted to the provider for storage and possible processing. To protect the consumer against the provider misusing their data, data processing legislation has been developed to ensure that the fundamental right to privacy is maintained. However, the distributed nature of Cloud Computing (in that Cloud services are available from anywhere in the world) makes is difficult to analyze every country's data protection laws for common Cloud architecture evaluation criteria. We have therefore chosen a common directive that applies as widely as possible and used the European Data Protection Directive (DPD) as a basis for our evaluation. Although it is an EU directive, countries that wish to engage in data transactions with EU Member States are indirectly required to provide an adequate level of protection and the Directive has had a far greater global impact than thus far acknowledged, making it an effective mechanism to raise the level of data protection worldwide (Birnhack, 2008) European Data Protection Directive EU Data Protection Directive (Directive 95/46/EC, 1995) is a directive adopted by the European Union designed to protect the privacy and protection of all personal data collected for or about citizens of the EU, especially as it relates to processing, using, or exchanging such data 1. All 27 EU Member States are reported to have enacted their own data protection legislation that transposes the directive into internal law, Canada, Australia and Argentina have implemented legislation that complies with the DPD, Switzerland has partially implemented legislation and the USA has voluntary registration to the Safe Harbor program to ensure private companies who sign up adhere to the rules set out in the DPD (Whittaker, 2011). The DPD has therefore been used in this evaluation as it is a commonly accepted and influential directive in the field of data processing legislation. It was produced in 1995, before Cloud Computing was developed, but can be applied to Cloud Computing as it describes how the protection of the processing of personal data and the free movement of such data should be achieved in a technology-neutral way. The DPD can be summarized as having elements concerned with the responsibilities of two actors involved in data exchanges and restrictions on the free movement of data between them based on their location Relevant roles defined in the DPD The requirements of the DPD are expressed as two technology-neutral actors or roles that have certain responsibilities that must be carried out in order to fulfill the directive. These roles, the data controller and data processor, are naturally equivalent to service consumer and service provider roles found distributed computing. According to the Article 2 of DPD (Directive 95/46/EC, 1995) a data controller is the natural or legal person which determines the means of the processing of personal data, whilst a data 1 What is EU Data Protection Directive 95/46/EC? Online: Whatis.com, 2008.

4 processor is a natural or legal person which processes data on behalf of the controller. However, following these definitions, a special case arises: if the processing entity plays a role in determining the purposes or the means of processing, it is a controller rather than a processor. Finally, although not a specific role, third parties are defined in Article 2 of DPD (Directive 95/46/EC, 1995) as any natural or legal person, public authority, agency or any other body other than the data subject, controller, processor and the persons who are authorized to process the data. This definition is further clarified in (Data Protection Working Party, Feb. 2010) by stating that such a third party has no specific legitimacy or authorization to process the personal data, therefore it is not involved in the controller-to-subject relationship. The DPD was designed to allow the free-flow of data between EU Member States. However, this directive also gives the opportunity to third countries to participate in free-flow activities, if deemed to implement adequate level of data protection (Article 25 of DPD (Directive 95/46/EC, 1995)). This condition means that a third country has to provide at least the same level of protection as the national provisions of the Member States. Once this condition is fulfilled, they can interoperate with other providers within the EU with no barriers Responsibilities associated to the roles of the DPD We have chosen the EU Data Protection Directive as legislation to evaluate current Cloud Computing use cases, since this directive is a widely-used and adopted set of rules governing Cloud Computing fundamentals. The DPD also introduces a set of responsibilities for the roles of data controller and processor. We can use these duties to form evaluation criteria to assess Cloud Computing use cases. The directive is also discussed in much detail with respect to Cloud Computing in (OPTIMIS, 2010), and provides a set of criteria that the roles must meet. According to these sources, the data controller must: Be responsible for compliance with data protection law. Comply with the general principles (e.g., legitimate processing) laid down in Article 6 of DPD. Be responsible for the choices governing the design and operation of the processing carried out. Give consent for processing to be carried out (explicit or implied, orally or in writing). Be liable for data protection violations. The data processor, meanwhile, must: Process data according to the mandate and the instructions given by the controller. Be an agent of the controller. Be a separate legal entity to the controller. These roles are strengthened if: The controller gives detailed instructions to the processor. The controller monitors the processor for the status of the processing. Relevant expertise can be shown to be present in either party (e.g., the processor is a specialist in it). A written contract exists between the controller and processor. The controller is able to exercise full and sole control at any time while the data processing takes place. The controller is informed of the main elements of the processing structure. Finally, in the evaluation of specific Cloud-usage scenarios we will assess location-related issues that may arise due to one of the establishments being outside a jurisdiction. In such cases, in general, an adequate level of data protection should be provided according to the EU DPD.

5 3. Architectural models of Clouds 3.1. View of the European Commission An expert group associated with the European Commission published their view on Cloud Computing in (Jeffery and Neidecker-Lutz, 2009). The report categorizes Cloud architectures into five groups, as shown in Fig. 1. Private Clouds (i) consist of resources managed by an infrastructure provider (IP) that are typically owned or leased by an enterprise from a service provider (SP). Usually, services with Cloud-enhanced features are offered, therefore this group includes SaaS (Software as a Service) solutions like ebay 2. Public Clouds (ii) offer their services to users outside of the company and may use Cloud functionality from other providers. In this solution enterprises can outsource their services to such Cloud providers mainly for cost reduction. Examples of these providers are Amazon 3 or Google Apps 4. Hybrid Clouds (iii) consist of both private and public Cloud infrastructures to achieve a higher level of cost reduction through outsourcing by maintaining the desired degree of control (e.g., sensitive data may be handled in private Clouds). The report states that hybrid Clouds are rarely used at the moment. In Community Clouds (iv) different entities contribute with their (usually small) infrastructure to build up an aggregated private or public Cloud. Smaller enterprises may benefit from such infrastructures, and a solution is provided by Zimory 5. Finally Special Purpose Clouds (v) provide more specialized functionalities with additional, domain specific methods, such as the distributed document management by Google's App Engine. This group is an extension or a specialization of the previous Cloud categories. Fig. 1. Cloud Architectures from the EC Report 2 ebay Inc. Online: Amazon Web Services. Online: Google Apps for Business. Online: Zimory GmbH. Online:

6 3.2. ENISA The European Network and Information Security Agency (ENISA) differentiates between four architectures (Catteddu and Hogben, 2009; ensia2), which are shown in Fig. 2. A Public Cloud (i) is a publicly-available infrastructure to which any organization may subscribe and use (also called as service consumers (SC)). Private Clouds (ii) offer services built on Cloud Computing principles, but accessible only within a private network. Partner Clouds (iii) are operated by a provider to a limited and welldefined number of parties. Finally, a Cloud Federation (iv) may be built up by aggregating two or more Clouds. Fig. 2. ENISA Cloud Architectures

7 3.3. NIST Cloud Architectures The National Institute of Standards and Technology (NIST) defines four deployment models (Mell and Grance, 2011; Liu et al., 2011) depicted in Fig. 3. According to their definitions, a Private Cloud (i) is an infrastructure operated solely for an organization that may be managed by either the organization or a third-party and located locally or remotely. A Community Cloud (ii) is shared by several organizations, and supports a specific community that has shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be managed by organizations or third parties, and may exist on premises or off premises. A Public Cloud infrastructure (iii) is made available to the general public or a large industry group, and is owned by an organization selling Cloud services. Finally, a Hybrid Cloud (iv) is a composition of two or more Clouds (private, community or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability (e.g., Cloud bursting for load balancing between Clouds). Fig. 3. NIST deployment models

8 The Cloud Computing Use Case Discussion Group (Cloud Computing Use Case Discussion Group, 2009) adopts the NIST models. They extend the view on Hybrid Clouds by stating that multiple Clouds work together, coordinated by a Cloud broker that federates data, applications, user identity, security and other details. Though a brokering mechanism is needed for federating Clouds, no specific guidelines are given how to achieve this. The Distributed Management Task Force (DMTF) Open Cloud Standards Incubator view (DMTF, 2009) has also adopted the NIST models and defined different scenarios showing how Clouds may interoperate. These scenarios explain how data centers interact with Cloud providers and differentiate three cases: If a datacenter, run by Service Provider 1 (SP1) and hosted by Infrastructure Provider 1 (IP1), exceeds the available capacity limits then IP2 provides extra computing capacity for IP1 and SP1 is unaware of this provisioning. In a multiple Cloud scenario, SP1 may operate services in both IP1 and IP3 Clouds, therefore a datacenter may request services from both providers since they may support different services or Service-level Agreement (SLA) parameters. A provider may act as a Cloud broker to federate resources from other providers (e.g., IP1 and IP2) to make them available to its consumers transparently without using any of its own resources OPTIMIS project The architectural views of the OPTIMIS project (Ferrer et al., 2012) are shown in Fig. 4. The project has three basic architectural scenarios. In a Federated Cloud Architecture (i), a Service Provider (SP) assesses an Infrastructure Provider (IP). IPs can share resources among each other. In a Multi-Cloud Architecture (ii), different infrastructure providers are used separately by a service provider. Finally in a Hybrid Cloud Architecture (iii), a Private Cloud (PC) is used by the SP, which can utilize resources of different IPs. Fig. 4. OPTIMIS Cloud architectures 3.5. Reservoir project The Reservoir project (Rochwerger et al., 2009) claims that small and medium Cloud providers cannot enter the Cloud-provisioning market due to the lack of interoperability between Clouds. Their approach is

9 exemplified by the electric grid approach: for one facility to dynamically acquire electricity from a neighboring facility to meet a spike in demand. Disparate datacenters should be federated in order to provide a seemingly infinite service computing utility. Regarding the architectural view, a Reservoir Cloud consists of different Reservoir Sites (RS) operated by different IPs. Each RS has resources that are partitioned into isolated Virtual Execution Environments (VEE). Service applications may use VEE hosts from different RSs simultaneously. Each application is deployed with a service manifest that formally defines its SLA contract. Virtual Execution Environment Managers (VEEM) interact with VEEs, Service Managers and other VEEMs to enable federations to be formed. A VEEM gathers interacting VEEs into a VEE group that serves a service application. This implies that a Reservoir service stack has to be present on the resources/sites of IPs. Their specialized Cloud architecture is depicted in Fig. 5. Fig. 5. Reservoir Cloud Architecture

10 3.6. Our unified view Fig. 6 shows an extended view of Federated Clouds incorporating private, public, multi- and hybrid Cloud architectures. Interoperability is achieved by high-level brokering instead of bilateral resource renting. Nevertheless different IPs may share or rent resources, but it is transparent to their management. Such a federation can be enabled without applying additional software stack for providing low-level management interfaces (Marosi et al., 2011). The logic of federated management is moved to higher levels, and there is no need for adapting interoperability standards by IPs (and some industrial providers are reluctant to do so). In this case, Cloud providers offering PaaS solutions may form sub-federations simultaneously to this approach. Specific service applications may be more suitable for such a solution, and projects like Reservoir (Rochwerger et al., 2009) and 4CaaSt 6 are working towards such a solution. Our approach targets IaaS-type providers, e.g., RackSpace, the infrastructure services of Amazon EC2, and providers using Cloud middleware such as OpenNebula or Eucaliptus. Fig. 6. Federated Cloud Management Architecture 6 4CaaSt EU FP7 project. Online:

11 4. Use cases exemplifying legal aspects 4.1. General usage scenarios The federated Cloud architecture described in Section 3.6 is now explored through a series of use cases to demonstrate where legal issues can arise in this general organizational structure. In these use cases the relevant actors and their roles (summarized in Section 2.2) will be identified and the necessary actions should be defined in order to prevent violations of the directive. As we will show, there are complications when personal data is transferred to multiple jurisdictions. Fig. 7. Common use cases: (a) with one infrastructure provider; (b) with different infrastructure providers The most common use case (C0) depicted in Fig. 7.a is when a user asks a service provider (SP) to store (and possibly process) their personal data. The SP leases Cloud resources from an infrastructure provider (IP) and the private data of the user is stored in a database (DB) and managed by a virtual machine (VM) located in an establishment (E) of the IP. In this simple case the SP is a data controller and IP is the data processor instructed by SP. However, there are questions that arise when this use case is extended. C1: When a SP offers the infrastructure to the user through directly a service front-end. In this case the SP, who is also an IP, is the data controller and there is no data processor. C2: When a Cloud service offered by SP1 is actually re-sold to the end-user from another service provider (e.g., SP2), either SP1 or SP2 may be the data controller. Therefore, if there is a chain of SPs the last entity contacting the IP will become the data controller and the instructed IP will be the data processor. C3: When an infrastructure provider (IP1) uses resources from a different provider (IP2) and, possibly for commercial reasons, this relationship is not made public, the SP using resources of IP1 is not aware of that it is using IP2 as shown in Figure 7.b. Therefore, when data moved from IP1 to IP2 for processing, IP1 will become the controller instead of SP, and IP2 will be the the processor instead of IP1. C4: In the situation where a user asks an SP to manage their private data, and the SP uses an IP for this task which has a public interface, the user may modify its data directly without involving the SP. Here, the user becomes the controller when accessing the database directly. C5: If a user asks two different service providers (SP1 and SP2) to manage two databases, and the user decides to migrate a part of the data from SP1 to SP2 by themselves, the user becomes the data controller

12 for the migration. C6: If an SP utilizes two different IPs (IP1 and IP2) for storing user data, and the user asks the SP to migrate data from IP1 to IP2, the SP will stay in the role of data controller and IP1 will remain the data processor since the SP instructed IP1 to do the transfer. If IP1 is not interoperable with IP2, the SP will fetch the data from IP1 and move it to IP2, so the initial roles will not change. Table 1 summarizes these general cases and depicts the relevant roles (data controller (DC) or data processor (DP)) the participating actors may play regarding data protection compliance. Table 1. Identified roles in common use cases. Use case User Service provider Infrastructure provider C0 - DC DP C1 - DC - C2 - DC DP C3 - DC DC & DP C4 DC DC DP C5 DC DC DP C6 - DC DP Fig. 8. Data distribution regulations related to EU Member States: (a) with one infrastructure provider; (b) with different infrastructure providers 4.2. Location-related cases In the following we discuss use cases where legal issues may arise due to private data processing at different geographical locations within the European Union 7. Article 4 of DPD (Directive 95/46/EC, 1995) states that the location of the data controller's establishment determines the national law applicable for data processing. In these cases let us consider the use case where a service managing private user data is deployed and executed in a datacenter of a Cloud Infrastructure Provider (IP) located in a EU Member 7 The DPD also applies to the EEA and EFTA countries according to (EEA Joint Committee, 2000).

13 State (MS). The service provider utilizes several IPs by aggregating them into a Cloud federation. The simplest use case (EU0) is where the SP, who is the data controller, has one establishment (E) located in a EU Member State. Here, the law applicable to data processing will be the national law of the MS regardless of the location of the IP. We now describe more complex cases (from the discussions of the Data Protection Working Party (Data Protection Working Party, Dec. 2010)) to identify the national law applicable. EU1: When an IP has facilities located in different Member States (e.g., MS1 and MS2). It distributes user data handled by a service on a virtual machine (VM1) using a database (DB1) in an establishment of MS1, and another service on a virtual machine (VM2) using a database (DB2) in an establishment of MS2. In this situation, IP will become the data controller, and at each establishment the corresponding national law has to be applied. EU2: Similar to the previous case, when an IP (established in MS1) has different establishments located in different Member States (e.g., MS1 and MS2), and it distributes user data between these establishments, the IP is again the data controller. In the specific case depicted in Fig. 8.a, the processing of the data by VM located in an establishment in MS1 involves data located in a different establishment in MS2, the law of MS1 must be applied. EU3: Similarly to use cases EU1 and EU2, when the IP has several establishments (possibly in a third country), and at least one of these is located in a MS, the applicability of this MS's law will be triggered and has to be applied in all establishments. EU4: Similar to case C3, if IP1 in MS uses resources from a different provider in a non-member State (e.g., IP2), the SP using IP1 may be unaware that it is using IP2. In this situation, IP1 is the data controller and IP2 is the processor and the law of the appropriate MS is applicable. When IP1 is located in an non- MS, and IP2 in a MS, again the law of the appropriate MS is applicable, and IP1 has to provide the adequate level of data protection as defined in the DPD. EU5: When an SP providing a federated Cloud management in an EU MS, and it utilizes different IPs and one of which (IP2) is located in non-ms - depicted in Figure 8.b. Since SP is the data controller and IPs are processors, the law of the SP's MS has to be applied (according to recital (18) in the preamble of DPD (Directive 95/46/EC, 1995)), and IP2 has to provide at least the same level of protection as the national law of MS. Otherwise, if IP2 cannot ensure an adequate level of protection, the decision making process should rule out IP2 from provider selection. EU6: If the SP providing a federated Cloud management (not necessarily in a MS) utilizes different IPs, one of which (IP2) is located at a MS. The SP is the data controller and IPs are processors. Since the establishment (or an equipment) of IP2 is located in a MS, the law of this MS has to be applied, and the establishments located in non-mss have to provide an adequate level of protection. Table 2. Location-related use cases. Use case SP IP National law applicable EU0 DC - E of SP EU1 - DC E x of IP EU2 - DC E i of IP EU3 - DC E MS of IP EU4 - DC & DP E MS of IP EU5 DC DP E of SP EU6 DC DP E MS of IP

14 Table 2 summarizes these location-related use cases, depicts the relevant roles (data controller (DC) or data processor (DP)) the participating actors (SP and IP) may play regarding data protection compliance, and specifies the entity, which location determines the national law applicable for data processing Summary and discussion Regarding the general use cases, Table 1 shows how the SP is mainly responsible for complying with the data protection regulation. When personal data is transferred to multiple jurisdictions it is crucial to properly identify the controller since this role may change dynamically in specific actions. We have seen how information on the exact location of the processing establishments is also of great importance in the use cases. Table 2 highlights that even if one datacenter resides in the EU, the law of the appropriate Member State of this data centre must be applied by the SP. In this section we have shown that identifying the relevant roles and the national law applicable to common Cloud Computing use cases is not straightforward. Cross-continental cases may further complicate the situation, e.g., when a US company stores data to a Cloud provider in France the French law will apply, and the exportation of the processed data back to the US will be restricted or prohibited (Gellman, 2009). Nevertheless, according to the discussion in (Commission Decision, 2000), if the European organization complies with the Safe Harbor privacy principles for the protection of personal data, the data is allowed to be transferred from a Member State to the US. 5. Recent developments and future steps in European legislation As we have seen in the previous section, new developments in legislation regulation applying to Cloud Computing are still needed. This situation is identified by Wong in (Wong, 2011), who gathered related steps of the Art. 29 Working Party to revise the directive and the European Commission has also initiated a public consultation 8, in the framework of their Digital Agenda, to find the requirements, barriers and opportunities for the provisioning and use of Cloud Computing that will contribute to a future European Cloud Computing strategy, scheduled to be published in According to a recent press release of the European Commission (EC Press release, 2012), they proposed a reform of the European data protection rules in a regulation (COM, 2012) that will replace the currently effective Data Protection Directive. Their main goal is to strengthen the users' influence on their personal data. They propose the following key changes: A single set of rules on data protection across the EU to avoid unnecessary administrative requirements. It places increased responsibility and accountability for the companies processing personal data (e.g. they must notify the national supervisory authority of serious data breaches within 24 hours). It promotes a single national data protection authority in each EU country that people can refer to, even when their data is processed by a company based outside the EU. These authorities will be empowered to fine companies that violate EU data protection rules. It strengthens the right to data portability by enabling easier access to users' personal data, and easier data migration among service providers. It introduces the 'right to be forgotten' to enable the deletion of user data upon request, when there are no legitimate grounds for retaining it. It explicitly states that EU rules must be applied for data processing outside the EU by companies that are active in the EU market. As we have seen in Section 4, the currently effective European DPD is basically appropriate for 8 Public Consultation on Cloud Computing by the European Commission. Online: August 2011.

15 determining the law applicable for data management in Cloud services, when the data controller and processor roles are well identified. What is more problematic for companies is to apply the identified law at a European scale, because the Member States implemented the DPD rules in different ways. This fact has also been recognized by the European Commission. In our opinion, instead of taking sanctions, it decided to perform a reform of the data protection rules using the principle of subsidiarity. Based on this principle the Union can introduce a unified legislation for data protection to be applied by all Member States. This reform will also give the opportunity for the Commission to replace the flexible directive with a strictly applicable regulation. Concerning our investigation, this proposal for a new regulation mostly clarifies, restates and strengthens the referred rules of the DPD. Only the so-called 'right to be forgotten' introduces a new responsibility for Cloud service providers. Some providers claim in the service usage terms and conditions to have the right to retain data, which may be affected by this new regulation. Even though it would definitely be a positive sign for the users and would encourage service utilization, but it would also place further development costs for providers, since the removal of all data replicas may also raise some technical problems. 6. Conclusion Many businesses are considering migrating their IT applications and data to Clouds to take advantage of the flexible resource provision such systems enable. However, remote resource provision brings with it new legal issues, such as data protection, licensing and intellectual property rights. In this paper we have gathered the corresponding responsibilities necessary for legal compliance from the Data Protection Directive of the European Union, and mapped the roles it describes to commonly-observed Cloud Computing use cases derived from a generalized model of different Cloud architectural views. As the directive also states that the location of the data controller's establishment determines the national law applicable for data processing, we have also examined usage patterns where different geographical locations of the relevant actors play a part. We can conclude that data protection is a far more complex problem in Cloud systems compared to traditional ICT systems. We identified dynamic roles changing as actions are initiated among the corresponding providers, which may also affect the national law applicable during service execution. Our future work plans to incorporate international legislations applying to Clouds considering crosscontinental cases. Acknowledgements The research leading to these results has received funding from the European Community's Seventh Framework Programme FP7/ under grant agreement (S-Cube). References 1. M. D. Birnhack, The EU Data Protection Directive: An Engine of a Global Regime, Tel Aviv University Law Faculty Papers, no. 95, Tel Aviv University Law School, L. A. Bygrave, European Data Protection, Determining Applicable Law Pursuant To European Data Protection Legislation, Computer Law & Security Report, vol. 16, no. 4, pp , R. Buyya, C.S. Yeo, S. Venugopal, J. Broberg, and I. Brandic, Cloud computing and emerging it platforms: Vision, hype, and reality for delivering computing as the 5th utility, Future Generation Computer Systems, vol. 25, no. 6, pp , June D. Catteddu and G. Hogben, Cloud computing Risk Assessment: Benefits, risks and recommendations for information security, ENISA report. Online: Nov D. Catteddu and G. Hogben, An SME perspective on Cloud Computing. Cloud Computing SME Survey, ENISA report. Online: November Cloud Computing Use Case Discussion Group. Online: August 2009.

16 7. COM (2012) 11 final, Proposal for a Regulation of the European Parliament and of the Council on the protection of individuals with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation), Brussels, Commission Decision no. 2000/520/EC of 26 July 2000 pursuant to Directive 95/46/EC of the European Parliament and of the Council on the adequacy of the protection provided by the safe harbour privacy principles and related frequently asked questions issued by the US Department of Commerce. Official Journal L 215, pp. 7-47, August Data Protection Working Party. Opinion 1/2010 on the concepts of ``controller'' and ``processor''. Ref. WP 169. Online: Feb Data Protection Working Party. Opinion 8/2010 on applicable law. Ref. WP 179. Online: Dec Decision of the EEA Joint Committee, No. 83/1999 of 25 June 1999 amending Protocol 37 and Annex XI (Telecommunication services) to the EEA Agreement, Official Journal 296, pp. 41, Nov Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data, Official Journal L 281, pp , Nov DMTF white paper no. DSP-IS0101, Interoperable Clouds, A White Paper from the Open Cloud Standards Incubator 1.0. Online: Nov EC Press release, Commission proposes a comprehensive reform of data protection rules to increase users' control of their data and to cut costs for businesses, European Commission, IP/12/46, 25/01/2012. Online: europa.eu/rapid/pressreleasesaction.do?reference=ip/12/46, Jan A.J. Ferrer et. al, OPTIMIS: a Holistic Approach to Cloud Service Provisioning, Future Generation Computer Systems, vol. 28, pp , R. Gellman, Privacy in the Clouds: Risks to Privacy and Confidentiality from Cloud Computing, World Privacy Forum, February 23, K. Jeffery, and B. Neidecker-Lutz, The Future of Cloud Computing, Opportunities for European Cloud Computing beyond 2010, Expert Group Report, January A. Cs. Marosi, G. Kecskemeti, A. Kertesz and P. Kacsuk, FCM: an Architecture for Integrating IaaS Cloud Systems. In Proceedings of the Second International Conference on Cloud Computing, GRIDs, and Virtualization (Cloud Computing 2011), IARIA, pp. 7-12, Rome, Italy, P. Mell and T. Grance. The NIST Definition of Cloud Computing, NIST Special Publication Online: September F. Liu, J. Tong, J. Mao, R. B. Bohn, J. V. Messina, M. L. Badger, D. M. Leaf, NIST Cloud Computing Reference Architecture, NIST Special Publication Online: September OPTIMIS FP7 project deliverable no. D , Cloud Legal Guidelines. Online: November B. Pring et. al., Forecast: Public Cloud Services, Worldwide and Regions, Industry Sectors, Gartner report. Online: June B. Rochwerger et. al, The Reservoir model and architecture for open federated cloud computing, IBM Journal of Research and Development, April D. Svantesson, and R. Clarke. Privacy and consumer risks in cloud computing. Computer Law & Security Review, vol. 26, pp , L. M. Vaquero, L. Rodero-Merino, J. Caceres, and M. Lindner, A break in the clouds: towards a cloud definition, SIGCOMM Comput. Commun. Rev. 39, 1, pp , Z. Whittaker, Safe Harbor: Why EU data needs `protecting' from US law. Online: April R. Wong, Data protection: The future of privacy, Computer Law & Security Review, vol. 27, issue 1, pp , February 2011.