Hybrid Cloud Architecture for Software-as-a-Service Provider to Achieve Higher Privacy and Decrease Securiity Concerns about Cloud Computing P. Reinhold et al 지능형 시스템 연구실 문성필

Outline Introduction Cloud Model Comparison Hybrid Cloud Architecture Implemented Prototype Conclusion

Introduction The increasing knowledge about cloud computing technology and its publicity leads to a growing number of service offerings over the Internet Even small and medium sized companies are able to offer services through cloud computing concepts Resource can be obtained easily from public cloud providers e.g. Amazon Web Services, Instagram

Introduction Many of these cloud services are provided in a form of Software-as-a-Service (SaaS) The high acceptance of these services suggests that private consumers have a lower privacy demand than business users Typical reasons are security and privacy This paper propose a hybrid cloud architecture enhanced with an additional architecture layer between business logic and persistence layer It has minimal migration effort and reveals no information, except for meta data

Cloud Model Comparison The table shows a comparison between the 3 cloud service models Privacy is low for public and medium for private cloud Private clouds have strong authorization and access control But, there is no special requirement to secure data The cloud provider often has access to customer data

Cloud Model Comparison The table shows a comparison between the 3 cloud service models Data-at-rest encryption is possible in all of the models But, strongly connected with key ownership and management If the same istance encrypts data and stores the referring key, that is not trustable security

Hybrid Cloud Architecture The aim of this paper is to combine the security of a private cloud and availability of a public cloud This paper proposed privacy-enhanced hybrid cloud architecture

Hybrid Cloud Architecture The architecture of this paper use AES for encryption The result of test about encryption algorithms, AES works most efficient

Hybrid Cloud Architecture Key concept The master key kM The master key is persisted by consumer The master key is used to encrypt / decrypt the data keys The data key dxky The data keys are persisted by the provider The data keys are used to encrypt / decrypt data The transfer key kT The transfer key are generated during the customers registration The transfer key are used for secure exchange of a temporary copy of the consumers’ master key

Hybrid Cloud Architecture The consumer uses a computer with Internet connection to access the SaaS The consumer has a master key for encryption

Hybrid Cloud Architecture The initial login and identification procedure should be located on physically separated hardware or be outsourced to a trusted ID verification provider

Hybrid Cloud Architecture The key management system, storing encryption keys, is another security critical resource and should not be integrated in the private cloud

Hybrid Cloud Architecture The private cloud structures contain the application server layer and encryption server layer

Hybrid Cloud Architecture All communication pass these tiers, so they have to be highly scalable The public cloud provider is illustrated in form of a persistence layer

Hybrid Cloud Architecture Security Overview After a successful login, the consumer allows the provider to decrypt the data keys dxky with its master key kM The data keys allow decrypting the data stored in the public cloud This method makes the consumer and SaaS provider trust the public cloud provider in next three scenario

Hybrid Cloud Architecture Threat Scenario A An attack against the public cloud provider Even if the attackers have full access to resources of the cloud provider, all data are secure Attack!

Hybrid Cloud Architecture Threat Scenario B An attack against the SaaS provider If SaaS provider is attacked, the attacker gets no access to consumer data Because the attacker can’t decrypt data keys Attack!

Hybrid Cloud Architecture Threat Scenario C An attack against the consumer The attacker obtains the login credentials, factors and the master key But the attacker can’t access to other consumer’s data Application servers of different consumers should be at least virtually separated Attack!

Implemented Prototype The private cloud servers Environment OpenNebula 4.4 CPU 3 GHz Dual-Cores RAM 8 GB Key Management VM (Virtual Machines) Load balancing Jboss mod_cluster 1.2.6 Gateway Apache http-Server

Implemented Prototype Client and server http POST requests for file uploads http GET requests for file downloads The client send SQL Queries to test the DB capability

Implemented Prototype Test Setup Started with a delay of 20s, send files While one client sends SQL queries Two file clients work after the following patterns ABABA A : UDD (upload, download, delete) 12 files of 1MB, 2s delay B : UDD 12 files of 1MB, 10ms delay Third client work after the following patterns CDC C : UDD 5 files of 10MB, 5s delay D : UDD 3 files of 10MB 10ms delay The simulated clients take 10m 23s

Implemented Prototype Test Results The result shows the percentage of times of each works to upload / download files to cloud The encryption and decryption times compared to upload / download times are so small

Conclusion Hybrid cloud architecture offers compromise for multiple reasons The solution addresses SME with experience in SaaS and own hardware infrastructure This model offers a higher security level and lowers privacy concerns of consumers The prototype includes scalable and flexible encryption servers With minimal key management system