Securing Database-as-a-Service: Issues and Compromises Joel Weis and Jim Alves-Foss Center for Secure and Dependable Systems University of Idaho
[email protected];
[email protected]
Abstract Database-as-a-Service is an example of one of many services being marketed as part of Cloud Computing. This paper addresses several major issues and concerns related to Database-as-a-Service, including data security, trust, expectations, regulations, and performance issues. Some general proposed resolutions are mentioned, such as risk management and better contractual agreements, before the discussion is turned toward some solutions for Database-as-a-Service specifically. The majority of solutions cover database encryption and authenticity techniques. Finally, we briefly address some hardware security concerns and then finish with a discussion of compromise and the balance of trust and risk. The goal of the paper is to educate the reader that Cloud Computing, specifically Database-as-a-Service, can be a reasonable technology to adopt when the issues and insecurities are understood.
1. Introduction Database-as-a-Service is one form of Cloud Computing. Today, there is a lot of hype about Cloud Computing in general. It is both promising and scary. Businesses see that it has great potential, but they also have many worries about it. This is natural, as it is a new business model with new security issues. Although the concept of time-shared remote services is not new, Cloud computing infrastructures utilize new technologies and services, some of which have not been fully evaluated with respect to security. Database-as-a-Service is a prime example of a new service that is both very promising and exciting to businesses, and also full of some of the most difficult security issues that Cloud Computing faces. This paper discusses the benefits of Cloud Computing, its various examples, and the context of Database-as-aService. Section 3 and 4 then discuss at length the various concerns, issues and shortcomings of Cloud Computing. After going over some things that can help Cloud Computing take hold as a valuable technology, several specific solutions for Database-as-a-Service are detailed. Overall the goal of the article is to educate the reader regarding some of the necessary compromises that must be understood before Database-as-a-Service, specifically, and Cloud Computing, in general, can be accepted as reasonable technologies. A primary assumption of this article, is that Database-as-a-Service is a worst case
scenario, security-wise, for Cloud Computing. There are several characteristics of Database-as-a-Service that make this a reasonable assumption, including the difficulties storing the relational data, querying the relational data, scaling the relational data, and maintaining the functionality of the original relational database. We therefore present examples of research to show that it can be implemented with some compromises and assumptions. Ideally, the issues and solutions presented here are evidence that we are close to a set of usable solutions.
2. The Cloud Rationale Economics is the primary cause for interest in Cloud Computing or Software-as-a-service. The idea is the first in a long time that has the potential to change IT forever [14]. What it promises is a cheap, reliable, and flexible alternative to today's collections of heterogeneous, rigid, monolithic, and expensive-to-maintain systems [12]. Each IT system that a corporation currently uses came about from the purchase of hardware, the development or procurement of software, and the funding for the professionals that maintain it [1]. In a cloud system, those things are all provided by the service provider, and in addition, the service is also extremely flexible. It can automatically balance loads, be more scalable, and is accessible anywhere there is internet. Businesses, government agencies, and other users all have the same reason for using cloud computing: cost. It is an obvious benefit for small business start-ups, where a large investment is necessary to set up a brand new IT infrastructure. Even enterprise class businesses find the advantages of cloud computing alluring. For example, when using cloud services, a business can eliminate the need for the professionals which maintain and support the underlying complexities for some of the most desirable new IT technologies, such as highly scalable, variably provisioned systems. One of the most obvious benefits to customers is that computing resources, such as virtual servers, data storage, and network capabilities, are all load balancing and automatically expandable. Resources are allocated as they are needed, and loads can be transferred automatically to better locations, producing a robust, reliable service [2].
2.1. The Cloud Paradigm
Cloud Computing can incorporate a large variety of modern internet technologies, such as grid computing, web applications, and virtual machines. It can also be thought of simply as the next natural step in Internet. Networking and the Internet began many years ago to further computing and collaboration. As technology has matured so has our use of computers for teamwork and cooperation. Now we are approaching a new age in the Internet where it is used as a medium to provide computing as a service to customers. The idea is simple enough. A large company, with lots of computing resources, such as large data centers etc, reaches an agreement with a customer. The customer can run their programs, store their data, host their virtual machines and so on, using the providers resources. Their contract can be terminated, the customer can avoid startup and maintenance costs, and they get the benefit of the providers ability to dynamically allocate their resources.
2.2. Types of Service Provider Models The term „cloud computing‟ used today is nothing more than a buzzword, derived in part from the idea of the telecommunications 'clouds' that VPN's were envisioned to pass through when they first began to see use. As a result, there is yet no clear definition for this term.. The same goes for most of the related terms. The following is a brief explanation of some of the most commonly presented cloud terms as used in this article. One classification for cloud types is Public or Private [2]. A public cloud exists when computing resources are made available as a service by a third party, like a utility. It is the most common meaning when the term cloud is mentioned. In a private cloud, however, the computing resources are owned and operated by the sole user of those resources. In this case, a business would be using their own resources to create many of the same advantages and technologies used in a public cloud. Because of its limited applications, a private cloud is usually only considered by enterprise-class businesses that own and control their own data centers. Cloud computing service providers typically provide one or more of the following types of resources, which creates a more common classification of cloud types: Infrastructure, Platform, or Software. Infrastructure-as-aService (IaaS) provides users with a basic computing environment. This allows the customer to build, load, and run their own virtual machines (often servers) in the cloud. The provider ensures that the machines have the necessary computing power and access to Internet bandwidth. Access from the client or customer side is via web services. Platform-as-a-Service (PaaS) provides users with an application environment. The development tools are provided, and the means to run and maintain the programs in a web environment are assured by the
provider. This paradigm has also been called Web 2.0. Depending on the platform, access can be via web services or through a browser. Software-as-a-Service (SaaS) provides users with a particular piece of software. The provider runs the software and provides internet access to it, but the user feeds it data and instructions. Access is almost always through a browser.
2.3. Where does Database-as-a-service fall? Database-as-a-Service (DaaS) is a prime example of SaaS [6]. The service provider picks the database management software, installs it, runs it, and manages it. Although the description may make it sound like the database used is some generic COTS Database Management System (DBMS), this usually isn‟t the case. Often they are custom applications developed by the service provider. This type of service has been used in private clouds for extremely large, non-relational databases, such as for search engines. In any of these cases, it is still just a software application provided to the customer. DaaS is particularly well suited, for economic reasons, to many small to medium businesses that rely on databases for so many things and find their installation and maintenance costs to be restrictive. Maintaining a database requires trained professionals, so the service provided is extra valuable because the customer does not have to hire, train, and pay them. It is important to remember the general motivation of DaaS is to make things easier. Relational databases have been in heavy use for decades because they provide constraints, control, and simplify the management of large amounts of related data. There are several major aspects of this cloud model that hinder the general cloud goal of making things easier. The first is encryption. This is the primary method for preserving confidentiality and integrity, and in aiding security of the data, but it also is extremely computationally expensive on the service provider side. Performing relational database tasks (running a query language) on encrypted data requires much more complex algorithms. There has been much research (for example, see [5], [7], [8], [9], [13], and [14]) on methods to perform queries on encrypted data, as well as creating encrypted indexes for the data. Currently the only way to maintain a fully encrypted database that can still function with most of the important features is to make a performance sacrifice that leaves the database unusable. The bottom line is that it is usually a step backward in our goal of making data management easier. Another critical part of the model is the database itself. This is the database that the service provider uses and maintains for the customer. The typical database in use today (relational database) can be expensive to maintain and is not very scalable [12]. Surely then, a service provider with many customers would have trouble maintaining and operating all of its databases. The
solution that currently exists in industry is a pseudodatabase [3]: a simple generic-container management system with little functionality. It is low-maintenance and highly scalable, although it means the standard SQL-like query languages needs to be replaced [12]. The lack of built-in constraints, controls, and management of the data means that businesses will find these „pseudo-databases‟ provide very little motivation to ditch their current local relational databases for a cloud solution. Only recently has research begun on making scalable relational databases, although security in these models is absent. Microsoft SQL Azure is an example of an early adoption of such a model. In the cloud market today, there are dozens of companies that offer secure storage, and many have added functionality to the storage and called them database services. These are more commonplace because they do not face all of the same issues as a scalable, secure, relational database run in the cloud. Nor are they as attractive. In fact, few cloud concepts do face as many problems, which is why we focus on this example of cloud computing; if it is usable, then so should be any other cloud services.
3. The Obstacles in the Cloud Given the benefits mentioned so far, it may be surprising that the adoption of cloud computing has been very slow. The fact is that businesses are reluctant at best to use cloud services. One glaring reason is the lack of trust that their data will be secure in the cloud. It turns out that this particular reason is only one of many, and not even the greatest concern [2], [4]. Many businesses have been storing private data in web email for years now, which is arguably a form of cloud computing [2]. An interesting thing about most of these concerns is that they are problems faced elsewhere (and accepted) in computing: they just appear in a new light in cloud computing. An examination of the concerns follows. Some of these concerns can be mitigated, and some will be seen as just another risk that has to be managed.
3.1. Adoption of a New Technology The first set of reasons businesses fear the cloud includes those that come with any new technology. Usually it must cross a 'hump' of acceptance before the use of the technology becomes widespread. The primary concern of most businesses is unstable operation [2]. Customers worry that there could be hiccups with these massive new cloud systems, and indeed there are. There are several notable examples with some of the largest providers, including older [4] and more recent Amazon outages. Customers also worry that their service provider won't last. Although the cloud computing market is expanding,
there is no way to judge stability in terms of a provider this early on. Another reason is fear of earning a bad reputation by sharing the fate of another customer using the same computing resources. It‟s not good for business to be associated with others that break the law, and in cloud computing it‟s impossible to know who's sharing the same resources. In March of 2009, one provider was shut down for an investigation into the possible criminal activity of one of the customers. Several other customers that were sharing the same resources went out of business because of the investigation and the lengthy downtime [2].
3.2. Expectations of the Service Provider A typical business interested in shifting to cloud services is used to having certain features available when implementing the services in question themselves. This section describes some of the features that become problematic when services are handled by a cloud provider. Sometimes it is simply rare a provider offers them, or they are extremely difficult to implement. In either case, this lack of familiar features is not helping cloud computing catch on. From our point of view, the number one service or feature that is missing is security of data. There are two levels of concern here. One is focused on preventing others (such as another customer) from reading private data. This is a clear and obvious concern and prominent in scenarios such as theft, or other direct malicious attack. The other is concerned with the service provider reading private data. Besides simple lack of trust of the provider themselves, it should be obvious that the service provider is not 100% immune to attacks or other malicious activity, targeted or otherwise. These two levels of concerns apply to other security issues as well, and of course are commensurate with the level of confidentiality desired. For most cases, some level of encryption is a given. In the case of DaaS, encryption can affect performance dramatically, as we discuss in Section 5. When security concerns are taken to an extreme, they include the physical security of the computing locations, residual data on disks when the service provider migrates data or replaces hardware, and even concerns about security in memory and processor management in the cloud machines. Another key facet that customers demand is the concept of completeness. It is important not only that they are assured of data integrity, but also that the content or data delivered to them is complete and the entire collection of data requested. One of the downsides to demanding extensive confidentiality and security from the cloud provider is that it tends to hinder investigative actions. Audits and investigations require as much knowledge and detail about the data and data events as possible. The strict security desired in the cloud, however, prevents the
creation or availability of this data. Businesses often want some kind of investigative and auditing options, just in case. Because of the nature of cloud computing, this is next to impossible. The same goes for knowledge of unauthorized access. Customers want the service provider to notify them if any such breaches occur. Typically this kind of monitoring and notification system is not available. Even if it were, if the service provider is considered un-trusted, which should be the default case, then there would be no reason to trust their monitoring solution if they had one [6].
3.3. Legal Issues There are legal concerns as well. These are not to be taken lightly as they are also the driving force behind many of the security issues. Businesses already face many regulatory requirements, privacy laws, and data security laws, and there's even more for government agencies. Probably the biggest dilemma is who is responsible for what (between the customer and service provider) when it comes to personal data. Some of the things that must be considered, because they apply somehow, include HIPAA, HITECH, GLB, FISMA, federal, state and local laws [15]. Exactly how each of these applies depends on the situation, the Service Level Agreement (SLA) between the customer and the provider, and the location of the data. The latter bringing a whole new concern to the board, since this is a factor that the user does not control and so usually does not know. It introduces a whole slew of legal problems, especially if the data crosses international boundaries [15].
4. Living with the Insecurity of DaaS It is clear that cloud computing has a long fight ahead of it to see widespread adoption. Luckily, many of the key battles are very similar to battles already fought and won in other areas of IT. Cloud computing still faces all of the problems traditional IT faces, but in a new context. In time, the application of regulations and laws will be tested and decided, and the services offered by providers (such as recovery and backup options, etc) will expand to suit the common customer demands. For some applications, cloud computing may never be suitable unless implemented in a private cloud. Here, the 'service provider' can be verified and trusted because it is operated by the 'customer.' Examples may include Multi-Level Secure (MLS) databases, or high-assurance applications that are concerned with information leaks via multi-core processors or memory sharing. While research is being conducted that shows that it might technically be possible to set up a system where these threats are mitigated appropriately, it will likely never come to a point where a public service provider system is adequately verified.
Several of the obstacles that have interfered with the adoption of cloud computing just need a larger perspective. While many focus on the security of data stored in the cloud, it should not be forgotten that all data in the cloud must pass through the internet, and its various security technologies, just to get to the customer. Internet data transmission security has been studied ceaselessly for decades, and the truth is that in modern day, only a certain level of security can really be expected. It is far from perfected, full of weaknesses and flaws, and can offer only a minimal amount of assurance [10]. This must be taken into account when demanding a higher level of security for the storage of data which can only be accessed via the internet. Thus we must learn to restrict our expectations of cloud security.
4.1. The Service Level Agreement The Service Level Agreement (SLA) is the only legal document between the service provider and the customer. That makes it a very important part of the service. It is the best way to mitigate and manage risks, understand the level of assurance available, and discover and deal with the insecurities. Of course, the document differs between providers, and it differs between types of cloud services. Unfortunately, there is such lack of standards for the SLA that it is a subject for concern [11]. Today‟s SLA‟s read much like an agreement for a minor utility. It focuses on billing, costs, waivers and exceptions. There is only a limited discussion of service-level expectations. Because it is the only legal agreement that the customer has with the service provider, the customer should leverage it to get the best service. Ultimately, at the signing of the SLA, the customer should have clear expectations of the service provider and service, and a clear understanding of the risks and assumptions being made while using the service. Currently, it is mostly up to the customer to investigate and question the provider. For cloud computing to advance it should be expected that all of the following issues be discussed, clarified and agreed upon in every SLA [11]. There are some issues that are simple business issues that should not be forgotten. This would include a precise definition of the service offered, and an agreement of how its performance is measured and reported. The responsibilities of both sides (provider and customer) should be outlined clearly, and a system agreed upon for managing any problems between the two. Other business items, such as warranties, remedies, company acquisitions, and termination conditions should also be discussed. The greater portion of the SLA should relate to security, an issue that is hardly mentioned in modern SLA‟s. The customer should know what the service provider is doing, or will do, about [11]:
Disaster recovery Physical security Logical security Privileged user access Restrictions on data location Segregation of customer data Customer auditing Auditing of service provider Support for investigations Regulatory compliance Data destruction Encryption key management Network security Some of these issues require an agreement between the customer and provider, while others require proof or services presented by the provider. Some, such as key management, will require the customer to provide information to the service provider. The customer needs to understand the level of service being provided and the risks involved, including the strength of the security solutions being offered. A service provider will not provide perfect security, but with an understanding of what is provided, the customer can make informed decisions.
4.2. Database Specific Issues Most of the obstacles that pertain specifically to DaaS must be overcome by settling on a compromise. Firstly, to maintain acceptable performance, some sacrifices must be made. There are actually a variety of reasons why such sacrifices are necessary, the greatest of which is the maintenance of security. In order to keep the data secure, and still remain usable, certain database features that customers are used to may be absent. Indeed, nearly all of the obstacles that DaaS faces can be overcome by making some sort of compromise on performance or features. This also adds to the customer‟s reluctance to adopt the technology. In fact, there are still some areas of DaaS that have not yet been studied because of the reluctance to make compromises which seem somewhat severe (this includes updating the database in the cloud [6], [14]: studies still focus on more basic database queries). The following section summarizes some of the security solutions being explored for DaaS.
5. Security Solutions for DaaS In this section we discuss the various places in DaaS where security is implemented. The following are some of the options a service provider has for implementing the database and its security.
5.1. Encryption in Databases Encrypted databases are nothing new. Various encryption technologies have been around for more than a decade. With a whole pile of data sitting in storage, encryption seems like the perfect security solution. However, cryptography (encryption and decryption) has its costs. It takes considerably more computing power, and this is multiplied by several factors in the case of a database. The biggest difference between the various methods of database encryption is granularity [8], [9], [13]. Some methods encrypt a tuple, some encrypt a relation, and some encrypt the whole database. The reason cryptography affects database performance so much is that each time a query is run, a large amount of data must be decrypted. Running queries is the primary purpose of the database, so this means that decryption operations quickly become excessive. Although, as mentioned earlier, there has been much research into the development of techniques to run queries on an encrypted database (for example, see [5], [7], [8], [9], [13], and [14]) solid and acceptable efficiency and performance is yet to be achieved. This is at least true for relational DaaS databases, which are admittedly the extreme case of the database encryption requirements. Early approaches began with extensions to the query language that simply applied encryption before writing a value, and running a decryption function before reading a value [8]. These types of extensions still exist in many commercial databases today, along with some more advanced counterparts [7], [9]. Even these counterparts are based on an absolute trust of the database management system. In a cloud environment, this trust is absent. Some proposed alternative solutions include binning techniques [6], privacy homomorphism encryption [6], early stopping comparisons, and separate encrypted indexes [13]. However, each of these solutions have their own compromises and downsides. Some are in the security of the data against certain attacks, and some are in the operations available to the customer. For example, homomorphic encryption is effective when doing summations on encrypted values, but is prohibitively slow for other operations, such as joins etc. Despite its severe limitations on performance [1], [9], there are few alternatives to using encryption to protect data in a database. One possible method has been developed by Agrawal et al [1]. The idea began as a way to ensure privacy by splitting data between two separate hosts that cannot communicate with each other (Fig. 1). Only the owner, who can access both hosts, can collect and combine the two data sets to recreate the original. The idea was later extended to apply to outsourced databases. It is proposed that the bits that make up one piece of data be divided mathematically so that it is not possible to infer the original data from either piece. This method is extremely fast compared to encryption, but requires at
least two separate, but homogenous, service providers. Unfortunately, it means the query engine must be running on a secure local server, which nullifies many of the benefits of a cloud database (a fairly robust IT infrastructure must be present, albeit without much disk storage). Further, it does not provide a clear way to protect the metadata (such as field names), although further extension of the technique could possibly address this.
Figure 1. Dividing data (Adapted from [1])
5.2. Key Management Naturally, if encryption is necessary to store data in the cloud, then the encryption keys cannot be stored there. Any key management system for any cryptographic method must be managed by and under the control of the customer. For simple encryption schemas, this may not be an issue, but almost any real database requires a more complex system. Oddly enough, this may take form as a small database. Similarly, for tokenization schemas, this means maintaining a secure local database, which again, defeats the general purpose of moving the original database to the cloud. Some schemas require a secure connection directly between the key management system and the database in the cloud. Clearly, this type of situation requires special arrangements with the service provider. There has been some recent research [5] that uses two-level encryption which successfully allows the key management system to be stored in the cloud. Although it has been shown to be efficient, it has not yet been applied specifically to database encryption.
5.3. Authenticity (Integrity and Completeness) In the common operations of a database, there exists a user with limited rights who wants to access a subset of
data, and in the context of DaaS, that user also wants to verify that the delivered results are valid and complete. To be complete means that the data is not poisoned, altered, or missing anything. A common approach to such a problem is to use digital signatures. The problem with digital signatures is that the user typically does not have access to the superset of data, so cannot verify any subset of data even if provided with the digital signature of the superset. There are too many possible subsets to maintain a digital signature for each, and the same problem exists for the case when the signatures are applied at the finest granularity level. In recent years, some research [6] has been conducted to find a solution to this problem. The basic idea is to provide the customer the signature of the superset, and some metadata along with the query results. This metadata, called verification objects, allows the customer to „fill in the blanks‟ of the data they don‟t have access to, and thus still validate the signature. There are two primary variations of this idea. One is based on Merkle trees, a concept created to sign multiple messages using binary hash trees, and the other is based on aggregation of signatures. The idea of completeness is the assurance that no data has been omitted from the result. It is often left to the realm of authenticity and integrity, but in the case of DaaS, it is becoming clear that this topic needs special attention due to the lack of trust. Indeed, the methods for showing completeness are basically the same as those used for authenticity. They also use Merkle trees or aggregate signatures, but include boundary records to aid in verification.
6. Other Issues There is an unmentioned, understood amount of security present when a business hosts its own IT infrastructure. It is in the machines themselves, the servers used for computation. They are usually built by the employees or bought commercially. They are secured with physical security, and most importantly, the business generally knows and restricts what is running on the machines. This provides some assurance of certain things we take for granted, until our data or application is out in the cloud. Typically in the cloud, likely even for DaaS, the business‟s data and applications are stored or running inside a virtual machine. This means that the virtual machine is probably running on a server with other virtual machines, some of which could be malicious. Although attacks against virtual machines, with virtual machines, and between virtual machines aren‟t known to exist in the wild, researchers have shown it is possible [4]. Assuming that such virtual machine attacks don‟t exist, or that an application isn‟t running within a virtual machine, the hardware then becomes an issue. Modern servers are typically multi-processor and probably multicore. There is research today that shows it is possible for
information to flow between cores on modern processors. This means that a secure application running on one core might unknowingly be passing information to a process on another core. It gets worse when it comes to memory. Multi-core processors often have complex caches, which makes the multi-core problem worse. This creates a big issue when decrypting in the cloud. If a value is decrypted in the cloud, even just for a moment for comparison, it exists unencrypted in the memory of some machine. The nature of the cloud is that we not only do not know where this machine is, we also do not know what else is running on the machine. It is possible that another malicious cloud user is monitoring the memory of the machine and reads our data, or that the provider themselves is monitoring the contents of the memory. Since the server is not under the control of the customer, and it is likely that the customer does not know anything about the server, it is obvious to question it. It is natural to question what malicious code is running on the server, whether the service provider is even aware, and who is running the code. The likelihood of these hardware attacks, however, is very small. With the advances in virtual malware, this may change in the future, but for now it remains a minor risk. The other thing to consider is that these are issues which are generally a concern for high assurance systems, which would face many larger threats from a cloud computing environment, such as typical internet attacks.
manageable, cloud computing will finally gain ground and take hold as a usable technology.
7. Conclusion
[6] E. Ferrari. "Database as a Service: Challenges and solutions for privacy and security", In IEEE Asia-Pacific Services Computing Conference (APSCC‟09), Dec. 2009, pp. 46-51.
Every cloud service has its issues, and the majority of them are security related. Although cloud computing still has many obstacles to overcome before it is adopted widespread, it can work now, in the right conditions. If businesses are careful about the questions they ask, demand a decent SLA, and understand the compromises, there is no reason why businesses can‟t begin enjoying cloud services today. As the DaaS example shows, there are still issues with some technologies, and performance concerns, but the vast majority of technologies can be explored. For those more difficult technologies, like DaaS, it may take some new breakthroughs in database encryption and querying before it is really viable. Even so, we probably won‟t have long to wait. The rest boils down to trust. The service provider creates trust by creating a decent SLA with the services and processes available to back up their assurances. The customer measures their trust by doing a risk evaluation. Only by understanding the risks they are taking can they understand the level of trust they can expect to have in any service provider. When the customers have the right level of expectations and the insecurities are deemed
8. References [1] D. Agrawal, A.E. Abbadi, F. Emekci, and A. Metwally. "Database Management as a Service: Challenges and Opportunities”, In IEEE 25th International Conference on Data Engineering (ICDE'09), April 2009, pp. 1709-1716. [2] M. Armbrust, A. Fox, R. Griffith, A.D. Joseph, R. Katz, A. Konwinski, G. Lee, D. Patterson, A. Rabkin, I. Stoica, and M. Zaharia. “A View of Cloud Computing”, In Communications of the ACM, Vol. 53, No. 4, April 2010, pp. 50-58. [3] F. Chang, J. Dean, S. Ghemawat, W.C. Hsieh, D.A. Wallach, M. Burrows, T. Chandra, A. Fikes, and R.E. Gruber. “Bigtable: A Distributed Storage System for Structured Data”, In ACM Transactions on Computing Systems, Vol. 26, No. 2, Article 4, June 2008, 26 pages. [4] R. Chow, P. Golle, M. Jakobsson, E. Shi, J. Staddon, R. Masuoka, and J. Molina. “Controlling data in the cloud: outsourcing computation without outsourcing control”, In Proceedings of the 2009 ACM workshop on Cloud computing security (CCSW '09), 2009, pp. 85-90. [5] S. De Capitani di Vimercati, S. Foresti, S. Jajodia, S. Paraboschi, and P. Samarati. “Encryption Policies for Regulating Access to Outsourced Data”, ACM Transactions on Database Systems, Vol. 35, No. 2, Article 12, April 2010, 46 pages.
[7] H. Hacigumus, B. Iyer, C. Li, and S. Mehrotra. “Executing SQL over encrypted data in the database-service-provider model”, In Proceedings of the 2002 ACM SIGMOD international conference on Management of data (SIGMOD '02), June 2002, pp. 216-227. [8] H. Hacigumus, B. Iyer, and S. Mehrotra. "Providing database as a service", In Proceedings of the 18th International Conference on Data Engineering (ICDE‟02), 2002, pp. 29-38. [9] J. Hu and A. Klein. “A Benchmark of Transparent Data Encryption for Migration of Web Applications in the Cloud”, In Proceedings of the 2009 Eighth IEEE International Conference on Dependable, Autonomic and Secure Computing (DASC'09), 2009, pp. 735-740. [10] M. Jensen, J. Schwenk, N. Gruschka, and L.L. Iacono. “On Technical Security Issues In Cloud Computing” In 2009 IEEE International Conf. on Cloud Computing, Sept. 2009, pp. 109116. [11] B.R. Kandukuri, R. Paturi V, and A. Rakshit. "Cloud Security Issues”, In IEEE International Conference on Services Computing (SCC'09), Sept. 2009, pp. 517-520.
[12] W. Lehner, and K.-U. Sattler. "Database as a service (DBaaS)", IEEE 26th International Conference on Data Engineering (ICDE‟10), March 2010, pp. 1216-1217. [13] E. Shmueli, R. Vaisenberg, Y. Elovici, and C. Glezer. “Database encryption: an overview of contemporary challenges and design considerations”, SIGMOD Record, Vol. 38, No. 3, Dec. 2010, pp. 29-34. [14] R. Sion. “Query execution assurance for outsourced databases”, In Proceedings of the 31st international conference on Very large data bases (VLDB '05), 2005, pp. 601-612. [15] L.J. Sotto, B.C. Treacy, and M.L. McLellan. “Privacy and Data Security Risks in Cloud Computing”, 15 Electronic Commerce & Law Report 186, BNA NEWS, Feb. 3, 2010, 6 pages.
