You are on page 1of 151

2011

Data Controlling In Cloud

VAMSI KRISHNA MANNAVA


SUPERVISOR: Dr. MUTHU RAMACHANDRAN

Student Id: 77090470 Course: MDCN Leeds Metropolitan University


9/23/2011

Data Controlling In Cloud

PREFACE
This document describes the dissertation work which carried out in The Faculty of Arts, Mobile & Distributed Computing Networks at Leeds Metropolitan University in the month of September, 2011. This dissertation submission report is in the accordance with requirements for MSc Mobile & Distributed Computing Networks (MDCN) Degree award under the university auspices.

ACKNOWLEDGEMENTS
Producing this Data Controlling in Cloud project has been the most advanced challenge I ever faced in my academic life. At first I am heartily and obediently thankful to my First supervisor Dr. Muthu Ramachandran and second supervisor Dr. Mark Dixon. Without this guidance, support, motivation and patience from the start to end made me understand and develop the knowledge and concepts of the subject. Otherwise it might not have been finished. I would like to say a special thanks to my first supervisor for all his encouragement and support to me. And the working experience with my professors will always be memorable to me. So finally I strongly say that I owe my deepest gratitude to my supervisors.

Abstract:
Cloud computing is the most recent and rapid evolving technology in the world of IT and Business. The cause of this much importance of cloud computing technology is due to its flexibility and cost-efficiency. Controlling the data in the cloud is always a nightmare to the cloud providers, because this data controlling is a security concern of cloud computing architecture. But with a small, easy and possible idea we can control the data in the cloud computing environment. The aim of this project is to investigate the possible ways to control the data in the cloud environments. Therefore, this project considered cloud architecture with specific attributes to handling and monitoring data security in the cloud. The observations are made using BPMN modeling which is useful to observe the business process modeling to control the data in cloud by using the new tools such as Bonita Open Solutions 5.5 for Modeling and Process Management and the Opnet for Network Simulation. In this project we have gone through a new idea with a special security concern called Clustering mechanism. This security concern is extremely useful to controlling the data in cloud by using these new tools which are motioned in the above.

General Terms:
Cloud computing, Cloud Security, Business Process Model in Bonita 5.5, Opnet simulation and Data controlling in cloud concept.

Keywords:
Cloud Computing, Cloud Architecture Security and privacy, Data Controlling in cloud.

Contents
PREFACE..........................................................................................................................................2 ACKNOWLEDGEMENTS.................................................................................................................2 Abstract: ............................................................................................................................................3 General Terms:...................................................................................................................................3 Keywords:..........................................................................................................................................3 Chapter-1 Introduction ......................................................................................................................11 1.0 1.1 1.2 1.3 1.4 1.5 1.5.0 1.5.1 Introduction:......................................................................................................................11 Rationale: ..........................................................................................................................11 Aim: .................................................................................................................................11 Objectives of this Investigation: ..........................................................................................12 Document Organization:.....................................................................................................12 Research Methods..............................................................................................................13 Methods & Approaches:..............................................................................................13 Cloud Business Process Design & Simulation: .............................................................15

Chapter-2: Introduction to Cloud Computing ......................................................................................18 2.0 2.1 2.2 2.3 2.4 2.5 Introduction.......................................................................................................................18 Cloud Computing Usages ...................................................................................................18 Five Essential and Common Cloud Characteristics ...............................................................19 Components of Cloud Computing .......................................................................................20 Service Delivery Models of a Cloud ....................................................................................22 Deployment Models of a Cloud: .........................................................................................24

Chapter-3 Taxonomy of a Cloud........................................................................................................26 3.0 3.1 3.1.1 3.1.2 3.1.3 Introduction.......................................................................................................................26 Taxonomy of a Cloud.........................................................................................................26 Cloud Service Consumer:............................................................................................27 Cloud Service Provider: ..............................................................................................27 Cloud Service Developer:............................................................................................29

3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.3 3.4

Cloud Computing Standards Relationships with Taxonomy ..................................................30 Standards Across The Cloud Service Types..................................................................30 Standards Within The Cloud Service Types..................................................................31 Standards Between Enterprise and Cloud .....................................................................32 Standards Within the Enterprise...................................................................................32 Application Programming Interface (API)s.........................................................................32 Roles of a Cloud Developer ................................................................................................34

Chapter-4: Cloud Data Security .........................................................................................................36 4.0 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 Introduction.......................................................................................................................36 Security Concern ...............................................................................................................36 Dangers and The Vulnerabilities of Cloud ...........................................................................37 General Cloud Security Requirements .................................................................................37 Security Levels and Questionnaire ......................................................................................39 Data Centre Security ..........................................................................................................40 Data Location ....................................................................................................................41 Data Backups ....................................................................................................................41 Sanitization of Data............................................................................................................42 Issues of Host Security .......................................................................................................42 Information Security ..........................................................................................................43 Network Security ...............................................................................................................44 Virtualization Security Issues .............................................................................................45 Vulnerability in the Virtualization .......................................................................................46 Risk Prevention at VMM....................................................................................................46 Cloud Encryption Scheme ..................................................................................................47

Chapter-5: Proposed Cloud Architectural Design ................................................................................52 5.0 5.1 Introduction.......................................................................................................................52 Design Concepts of Proposed Cloud Architectural Design ....................................................54

5.1.1 5.1.2 5.1.3 5.2 5.3

Client:........................................................................................................................54 Cloud Provider: ..........................................................................................................55 Cloud Management:....................................................................................................55 Advantages of our Proposed Cloud Process Design ..............................................................57 Data Flow Diagrams ..........................................................................................................58

Chapter-6 Business Process Modeling for Simulation of Cloud Data Control Architecture and Workflow using Bonita Tool .............................................................................................................................62 6.0 6.1 6.2 6.3 6.4 6.5 6.6 6.5.0 6.5.1 6.5.2 6.5.3 6.5.4 6.5.5 6.5.6 6.5.7 Introduction.......................................................................................................................62 What is a Business Process? ...............................................................................................62 Business Process Modeling Assumptions ............................................................................63 Business Process Modeling Environment ............................................................................63 About BOS-5.5 ..................................................................................................................64 Cloud Business Process Design...........................................................................................66 Bonita Simulation Results Regarding to the Proposed Design ...............................................67 Cloud Provider Simulation Details: ..............................................................................67 Load Profile: ..............................................................................................................68 Execution Time: .........................................................................................................68 Waiting Time: ............................................................................................................76 Cumulated Time: ........................................................................................................83 Cloud Provider Consumption: .....................................................................................83 Cloud Provider Cost Estimation:..................................................................................85 Cloud Provider Utilization: .........................................................................................86

Chapter-7: Network Modeling ...........................................................................................................88 7.0 7.1 7.2 7.3 7.4 Introduction.......................................................................................................................88 Assumptions of Network Modeling .....................................................................................88 Applications Which Involved in the Proposed Architecture ..................................................88 Network Simulation Environment .......................................................................................89 Physical Hierarchical Design ..............................................................................................90

7.5 7.4.0 7.4.1 7.4.2 7.4.3 7.4.4 7.4.5 7.4.6

Network Simulation Results and Analysis with Respect to Proposed Network .......................94 Network Delay Statistical Results: ...............................................................................95 DB Query Statistical Results: ......................................................................................96 E-mail Server Statistical Results: ............................................................................... 100 HTTP Statistical Results: .......................................................................................... 105 FTP Statistical Results: ............................................................................................. 110 IP Statistical Results: ................................................................................................ 115 Network Utilization: ................................................................................................. 117

Chapter-8: Conclusion .................................................................................................................... 120 8.0 Evaluation & Future Work: .............................................................................................. 120

Appendix - A ................................................................................................................................. 121 Chapter-9: Bibliography.................................................................................................................. 148

List of Figures
Figure 1: Clustering Mechanism (Assumption) ...................................................................................21 Figure 2: Cloud Service Level Architecture (Assumption) ...................................................................22 Figure 3: Taxonomy of a cloud computing (opencloudmanifesto, 2009) ...............................................26 Figure 4: Cloud Service Consumer (opencloudmanifesto, 2009) ..........................................................27 Figure 5: Taxonomy of a cloud computing (opencloudmanifesto, 2009) ...............................................28 Figure 6: Service Developer (opencloudmanifesto, 2009) ....................................................................30 Figure 7: Standards Taxonomy Types of Standards (opencloudmanifesto, 2009)...................................30 Figure 8: Cloud Computing Scale (Saurabh, 2009)..............................................................................36 Figure 9: Relationship between data and policies (assumption) ............................................................41 Figure 10: Host Security (Saurabh, 2009). ..........................................................................................43 Figure 11: Information Security (Saurabh, 2009). ...............................................................................44 Figure 12: Risk Protection (Saurabh, 2009). .......................................................................................47 Figure 13: Symmetric encryption/decryption process (Assumption) .....................................................48 Figure 14: Asymmetric encryption/decryption process (Assumption) ...................................................49 Figure 15: Data Request flow from Client to Cloud (Assumption Design using Bonita).........................54 Figure 16: Client Management Team and the Its Security Pool (Assumption Design using Bonita) ........55 Figure 17: Data Center over view according to our proposed network (Assumption Design using Bonita) ........................................................................................................................................................56 Figure 18: Intrusion Rejection Process (Assumption Design using Bonita) ...........................................57 Figure 19: Bonita Studio Version.......................................................................................................63 Figure 20: Bonita Studio Futures .......................................................................................................64 Figure 21: Business Process Model Design of Data Controlling in Cloud in Bonita............................66

Figure 22: Load Profile .....................................................................................................................68 Figure 23: Cloud Provider Instances Execution Time ..........................................................................69 Figure 24: Cloud Provider Execution Times by instances ....................................................................69 Figure 25: Data Check-In Instances Execution Time ...........................................................................70 Figure 26: Data Check-In Execution Time by Instance ........................................................................70 Figure 27: Data Mode for Transmission Instances Execution Time ......................................................71 Figure 28: Data Mode for Transmission Execution Time by Instance ...................................................71 Figure 29: Data in Motion Instances Execution Time ..........................................................................72 Figure 30: Data in Motion Execution Time by Instance .......................................................................72 Figure 31: Data Security Area Instances Execution Time ....................................................................73 Figure 32: Data Security Area Execution Time by Instance .................................................................73 Figure 33: Raise Alarm Instances Execution Time ..............................................................................74 Figure 34: Raise Alarm Execution Time by Instance ...........................................................................74 Figure 35: Compose Rejection E-mail/Msg to Client Instances Execution Time....................................75 Figure 36: Compose Rejection E-mail/Msg Execution Times By instances ...........................................75 Figure 37: Cloud Provider Instances Waiting Time .............................................................................76 Figure 38: Cloud Provider Waiting Times By instances.......................................................................76 Figure 39: Data Check-In Instances Waiting Time ..............................................................................77 Figure 40: Data Check-In Waiting Time by Instance ...........................................................................77 Figure 41: Data Mode for Transmission Instances Waiting Time .........................................................78 Figure 42: Data Mode for Transmission Waiting Time by Instances.....................................................78 Figure 43: Data in Motion Instances Waiting Time .............................................................................79 Figure 44: Data in Motion Waiting Time by Instances.........................................................................79 Figure 45: Data Security Area Instances Waiting Time .......................................................................80 Figure 46: Data Security Area Waiting Time by Instances ...................................................................80 Figure 47: Raise Alarm Instance Waiting Time...................................................................................81 Figure 48: Raise Alarm Waiting Time by Instances.............................................................................81 Figure 49: Compose Rejection E-mail/Msg to client Instances Waiting Time........................................82 Figure 50: Compose Rejection E-mail/Msg to client Waiting Time by Instances. ..................................82 Figure 51: Cloud Provider Instances Cumulated Time .........................................................................83 Figure 52: Cloud Provider Consumption ............................................................................................83 Figure 53: Cloud Provider Consumption by Instance...........................................................................84 Figure 54: Cloud Provider Global Consumption .................................................................................84 Figure 55: Cloud Provider Cost Measurement ....................................................................................85 Figure 56: Cloud Provider Cost Measurement by Instance ...................................................................85 Figure 57: Cloud Provider Global Cost ..............................................................................................85 Figure 58: Cloud Provider Utilization ................................................................................................86 Figure 59: Cloud Provider Utilization by Instance...............................................................................86 Figure 60: Cloud Provider Total Utilization........................................................................................86 Figure 61: OPNET Modeler 14.5 .......................................................................................................89 Figure 62: A Sample Basic Cloud Computing Architecture .................................................................90 Figure 63: Inner View of Cloud Provider............................................................................................91 Figure 64: Inner View of Cloud Presentation/Web Tier .......................................................................91 Figure 65: Inner view of Cloud Application Tier.................................................................................92

Figure 66: Inner View of Cloud Database Tier....................................................................................92 Figure 67: Inner View of Client-1 ......................................................................................................93 Figure 68: Inner View of Client-2 ......................................................................................................93 Figure 69: Inner View of Client-3 ......................................................................................................94 Figure 70: Network Delay of our proposed network (in time average). .................................................95 Figure 71: DB Query Response Time (in time average). ......................................................................96 Figure 72: DB Query Traffic Received (packets / Sec) ........................................................................97 Figure 73: DB Query Traffic Received (bytes / Sec) ...........................................................................97 Figure 74: DB Query Traffic Sent (packets / Sec) ...............................................................................98 Figure 75: DB Query Traffic Sent (bytes / Sec)...................................................................................99 Figure 76: E-mail Server Download Response Time (in time average). .............................................. 100 Figure 77: E-mail Server Upload Response Time (in time average). ................................................... 101 Figure 78: E-mail Server Traffic Received (packet/sec). .................................................................... 102 Figure 79: E-mail Server Traffic Received (bytes/sec)....................................................................... 102 Figure 80: E-mail Server Traffic Sent (packet/sec)............................................................................ 103 Figure 81: E-mail Server Traffic Sent (bytes/sec). ............................................................................. 104 Figure 82: HTTP Page Response Time (in time average). .................................................................. 105 Figure 83: HTTP Object Response Time (in time average). ............................................................... 106 Figure 84: HTTP Traffic Received (bytes/sec). ................................................................................. 107 Figure 85: HTTP Traffic Received (packets/sec)............................................................................... 107 Figure 86: HTTP Traffic Sent (packets/sec). ..................................................................................... 108 Figure 87: HTTP Traffic Sent (bytes/sec). ........................................................................................ 109 Figure 88: FTP Download Response Time (in time average). ............................................................ 110 Figure 89: FTP Upload Response Time (in time average). ................................................................. 111 Figure 90: FTP Traffic Received (packets/sec).................................................................................. 112 Figure 91: FTP Traffic Received (bytes/sec). .................................................................................... 112 Figure 92: FTP Traffic Sent (packets/sec)......................................................................................... 113 Figure 93: FTP Traffic Sent (bytes/sec). ........................................................................................... 114 Figure 94: IP Network Convergence Activity (in time average). ........................................................ 115 Figure 95: IP Traffic dropped (in time average). ............................................................................... 116 Figure 96: Network Utilization-In (Point-to-Point)........................................................................ 117 Figure 97: Network Utilization-out (Point-to-Point) ...................................................................... 118

Introduction
(Chapter - 1)

Chapter-1 Introduction
1.0 Introduction:
Nowadays the multinational organizations operate the capitalization of marketing everything in the cloud. The major corporations putting the less sensitive data in clouds, in this aspect the lack of data controlling in cloud is the most worrying thing. By the controlled manner there is possibility to get the mutual benefits for all the cloud participants. But controlling the data is the most challenging task to the Cloud Service Providers. This document explores that with an implementation of a tiny idea the Cloud Service Providers can control the data efficiently and also it is easy to provide the security easily. To execute this new idea, there is some highquality and useful tools are recommended, such as Bonita Open Solutions 5.5 for Modeling and Process Management and Opnet for Network Simulation.

1.1 Rationale:
The IT sectors know how the cloud computing is playing a lead role in the world of IT and its development. It is happening only due to the security cost efficiency for all organizations. Many of the organizations are expanding their corporate networks in a large scale manner. Cloud Computing offers many opportunities to them for their data security and accessibility anywhere in the world where the internet is available. As an aspiring computer network engineer, I am very interested to investigate the ways of data controlling mechanism in the cloud computing networks is, by using a small controlling idea and also without any major modification of existing cloud network.

1.2 Aim:
The main aim of this project is to investigate the secure ways of controlling the data to improve the network performance of a Cloud in the Cloud Computing Architectures.

1.3 Objectives of this Investigation:


The aim of this investigation process has been accomplished through the bellow objectives. Such as, Observe the drawbacks of existing cloud computing network. Find out difficult areas where the cloud providers are facing troubleshoots. Improve the knowledge on cloud security and its issues. Design the process model by using the best corporate modeling tool i.e., Bonita. Design a simple network diagram according to the business process model by using the simulation tool i.e., Opnet and get some simulation results in both Bonita and Opnet tools. Finally compare the results.

1.4 Document Organization:


This dissertation document consists of 9 chapters. The 1st chapter of this document explores the aim, rationale, objectives, document organization and research methods. The 2nd, 3rdand 4th chapters explore the literature review on all aspects of Cloud Computing, Taxonomy of Cloud and The Cloud Data Security. The 5th chapter explores about Proposed Cloud architectural Process Design. The 6th chapter explains the simulation results of my proposed Cloud architectural Process Design by using Bonita Open Solutions 5.5. The 7th chapter explains simulation results with respect to Cloud architectural network design. The final chapter is entirely on conclusion with summarising the dissertation and future work findings.

1.5 Research Methods


1.5.0 Methods & Approaches:
Research is a process of new thoughts. But in my view Research is a process of choosing the subjective side area and also answers the queries like why, what and how. The answers or the procedure of the research questions can acquire by several types of met hods called the research methods. These research methods are broadly classified in two ways such as, Quantitative Methods Qualitative Methods Each of these methods is having some advantages as well as disadvantages. The quantitative method analysis is all about collecting the data chunks and also analyzing the results of the data (Denscombe, 2003). The best quantitative method example is survey analysis. But, in this project I am going through the qualitative method analysis because the qualitative methods are defined as the verification of statement correctness. And also these qualitative methods are all about an in-depth analysis and study of subjective area. So, my dissertation topic needs an indepth study and hypothesis of subjective area. But the quantitative methods are not suitable to this dissertation. The reason is, this project does not need that much human involvement and also the subject area doesnt require any wide range of events or people. The only thing in the qualitative research strategy used in this dissertation is case study simulation. The case study is defined as research strategy than research method (Denscombe, 2003). The major drawback of case study approach is it focuses on only one instance at a time than broad range events. The research questionnaires in this dissertation are, How much performance risks that the cloud providers are facing with client data requests? What are the security risk factors if the cloud providers are unable to control the data? In this project I am approaching double mode research strategies which involve simulation mechanism and as well as case study. We already know that the case study is described as strategy of research than a method of research. Beyond this reason the case study

forms research basis. This case study is having some features like internet and survey research. When these features are all brought together, then it forms a subject area of research approach in a broad view. The major features of this case study are as follows, Spotlight on a Single Instance An in-depth Study Focus on Processes &Relationships Multiple Methods & Sources (Denscombe, 2003)

More details about each future of the case study is explained in the bellow,

Spotlight on a Single instance:


The basic point or the initial point to implement the case study technique is to concentrate or focus on a particular single subjective instance area. This enables researcher to get an in-depth incitement of the particular instance (Denscombe, 2003). In this project the subjective field which we have chosen is Data Controlling in the Cloud. Some specific questions about this dissertation task are: How does the performance of cloud impact on the client? What is the investigative way to solve this problem? Which security aspect of cloud you need exactly? Have you aware of encryption and decryption algorithms? Finally how good result you get with all of these?

An in-depth study:
In order to solve the above questions, an in-depth study is essential. This in-depth study involves studying the subjective area and its concepts which underpinning in detail. This is impossible by the survey methodology because the survey methodology concentrates only on a wide subjective spectrum and also the outcomes which are achieved by survey methodology cant be accurate as case study result. The case studies will focus on a single instance as a subjective area to deal highly opportunities than quantitative methodology (Denscombe, 2003).

Focus on Processes & Relationships:


After Studying of all the subjective area in a detailed manner the interrelationships between various subjective aspects can be found. In this project after studying all about cloud computing and its data security, I have identified a performance problem which the clients are facing by the cloud providers. So, thats way I have gone through the business process simulation in Bonita Open Solution 5.5 for internal process and also for network performance I have conducted OPNET simulation by using a small cloud design (Denscombe, 2003).

Multiple Methods & Sources:


The major strength of case study methodology is it allows several kinds of methods and sources usage to study and investigate the subjective area. In this approach of case study I have referred online books, text books, articles and also e-journals to study the cloud computing subjective area. Qualitative method is used for introspection.

1.5.1 Cloud Business Process Design & Simulation:


The simulation tools which are used in this dissertation are Bonita and Opnet. Experimental part of this dissertation consists of three phases (Denscombe, 2003). Control Factors Identification Causes & Effects

Observations & Measurements. Control Factors Identification:


The key important factors which will affect the experiment variables are Control Factors. The variables which we selected are Delay, DB query, E-mail, Ftp, Http, IP, Network Utilization etc These all control factors will be identified by the case study which is carried out.

Causes & Effects:

In the experiment the control factors can cause several including or excluding effects on variables. The analysis which cause to these effect reveals the variable and control factors relationships.

Observations & Measures:


The measurements of control factors and its effects on variables are finally accomplished. The measured analysis values are explained. To find out control factors causes & effects on variables, the simulation process has been designed in three scenarios. In the first scenario the delay of general cloud is measured without implementation of our cloud data control process. In the next scenario the other control factors are implemented on clouds network topology and also it has been examined. In the final scenario all the factors on cloud data controlling mechanism variables are tested. The observation phase and measurement phases are accomplished by Opnet simulation graphs in time average scale. All the results and conclusion are explained in detail in the last chapters.

Literature Review
(Chapters - 2nd, 3 rd and 4 th )

Chapter-2: Introduction to Cloud Computing


2.0 Introduction
Cloud computing is a model to deliver and enable convenient environment for the services and applications in on-demand network access basis. Still it is a developing technology in IT and business environments. But it definitions, issues, depending technologies, risks, benefits and use cases will be refined by private and public sectors in spirited debate. All these attributes, characteristics and definitions are subject to change and evolve. The cloud computing environment represents a huge ecosystem of so many market niches, models and multiple vendors. So, this definition encompasses various approaches of all cloud environments. Due to this cloud computing the organizations expenditures on equipment, software license agreements and many more are greatly reduced, because this technology is strictly independent on locations and devices, and also it enable the clients/ e nd users to access the systems using the web browsers (like internet explorer, Mozilla Firefox, Netscape, Google Chrome etc..) regardless of what devices and OSs they are using and their location. So, as part of literature review, in this chapter I have described all about cloud computing and its deployment, service models and characteristics.

2.1

Cloud Computing Usages

It doesnt matter how large is the Cloud Computing architecture is, but its all the matter how best is that architecture providing the services to the client. The following are some of basic and most significant usages of a cloud computing architecture. It helps the client to use the applications whatever he wants, without any installation. By using the internet access client can access any of his personal files at any computer. The cloud computing offers more efficient computation to the user by bandwidth and processing, centralizing storage system, and memory. The client can pay only for how they use.

2.2

Five Essential and Common Cloud Characteristics


Every Cloud Computing Architecture consists of several characteristics. Lets take a

further step to define the essential and Common Cloud characteristics.

The Five essential Cloud Characteristics:


Rapid Elasticity: Elasticity is defined as ability to scale both the up & down resources as needed. In client/consumers view cloud is an infinite and he/she can purchase the computing power as much as they can and as little as they can. This is one of the major characteristic of cloud computing technology. On-Demand Self-Service: The On-Demand Self-Service means that a client/consumer can access the cloud services without any cloud providers human interaction as needed. Measured Service: In this aspect of Measured Service, all the cloud services are managed, monitored and controlled by the cloud provider. This is necessary for resource optimization, billing, capacity planning, access control and the other tasks. Resource Pooling: It makes the cloud provider to serve their consumers by using multi- tenant model. On demand of consumer the virtual and physical resources will be assigned and reassigned. It makes sense of location independence because the consumer doesnt have the knowledge on where the resources provide the services. But the cloud specifies these details (like state, country or datacenter) in the abstractions higher level. Broad Network Access: It means for the both thin and thick clients all the capabilities of cloud provider whatever they need are available through the network and also they can access via standard mechanisms.

Common Cloud Characteristics:


Service Orientation: It means Service Level Agreements (SLA), a contract between the Cloud provider and Consumer. These specify the requirements of consumer and commitments of cloud provider to them. Critically these service orientations include the tasks such as security, uptime, privacy and backup procedures.

Multi-Tenancy: Its a property of multiple applications or systems or data from same physical hardware which enterprises hosted differently. This is a common characteristic of most of the cloud-based systems. Inte roperability: Its an ability of the cloud computing systems to communicate with each other. In this phenomenon the communicated information must able to understand by the destination system. Clo ud Computing technology need this interoperability concept because the ability to write the code which can work in two or more cloud provider devices simultaneously and regardless of cloud provider differences. Virtual Machines: A file when executed that appears to the user as an actual machine. Typically we can call a file as an image. Infrastructure as a Service in the cloud technology is often providing as Virtual Machine (VM) image which we can stop and start as needed. Portability and Integration: The term Portability means ability to access the devices and systems which belong to one environment in the other environments. This portability includes virtual and physical environments (both software and hardware). And the term Integration is a process of clubbing different systems or devices in an overall system. Low Cost: The services which the cloud computing technology provides that costs very low.

2.3

Components of Cloud Computing


Nowadays for every successful cloud computing architecture consists of several

fundamental components. Because of these this things we can understand Why the Cloud venture is too expensive? These essential components play a key role in the cloud architectures. The following are some of the cloud computing components which are necessary in the cloud computing architectures. Such as, Web Applications: Web applications are the applications which have been created by using the standard World Wide Web technology languages such as Java

Script, HTML, and XML etc (For example Google docs, quick books, Google spread sheets and many more). Clusters: The clusters in the cloud computing are normally used for DB servers like MS active directory, My SQL and so on. In this clusters phenomena the load of cloud is balanced between the servers. If one server failed then the cluster responds and doesnt send the traffic to that crashed one. By replication mechanism all these servers maintains same data. When the request comes here then these all servers will talk to each other and process. The figure explains how exactly the clustering mechanism works. Terminal Services: Terminal Services is an architecture which is based off of early days mainframe and dump terminal architecture. Now we use Terminal Services Servers and Thin Clients. These Thin Clients can be the Software or Hardware devices which installed on the computer. The Thin Clients are connected to the Terminal Services Server with a small device. All these Thin Clients share the CPU power from the Terminal Services Server because all the processors, hardwares are reside at here only. The Thin Clients can only get a window from the server. Application Servers: In Terminal Services Server and Thin Client concept, instead of accessing full environment they access/delivers a specific application. These are not web applications. The actual meaning of an Application Server is that a server holds the real application like Photoshop etc Virtualization: Virtualization is a concept of separation of OS from the H/W that runs on the OS. These concept software comes in two elements: Client Installed: It means Installation of another OS on top of the default OS. Hype rvisors: In this virtualization environment we are going to deal with two slices of software. When you install VMware you install Hypervisors (Ex: ESXI) in the hardware it gives you few information like IP address and MAC
Figure 1: Clustering Mechanism (Assumption)

address. And the next slice of software is Management software (Ex: VSphere). This software runs through the Hypervisor. The VSphere connects through internet with ESXI. Then all of our clients can now use Virtualization. Even though all Virtualization softwares (Ex: VMware, Citrix and etc) are free but we have to pay for the Management Software. Hosted Instances: Hosted instances (Ex: Microsoft Azure, Amazon EC2 etc) are the things which you have to pay for the use of several things like CPU power, Storage Amount, Bandwidth and RAM. The edge locations can be used by some cloud providers for faster access of the servers over internet. But we might charge to send the data to Edge servers from main servers. Hosted Solutions: Hosted solutions are the pieces of software which are hosted by the cloud vendors (Ex: Google Docs, Mozy, Hosted Exchange, and Adobe Acrobat.com).

2.4

Service Delivery Models of a Cloud


There are three major and basic types of

service delivery models in the cloud; such as,

Software as a Service (SaaS):


The most common thing which we see always is SaaS (Software as a

Service).A service provider gives license of an application to the client for use as a service model on demand. By this service delivery model the client can only use applications over the network but he cant control the network infrastructure, hardware or operating systems which that application is running. The above figure clearly describes the service level architecture of a cloud. The following are usage area of SaaS model.
Figure 2: Cl oud Service Level Architecture (Assumption)

Usage Areas: Internet services, Government Applications Social networking sites, Twitter/Blogging/Surveys Collaboration (E- meeting), Communication (E-mail) Enterprise Resource Plannings (ERPs) Knowledge/Information Sharing (WIKI) Productivity Tools (Office)

Platform as a Service (PaaS): In this service delivery model the client utilizes
computing platforms and the solution environment stack for his applications because all the platforms may not compatible with the each other. And this service model deploys the client created applications to the cloud. By this model the client can only control the applications which run in that environment, but he cant control network infrastructures, hardwares or operating systems that environment is running. The following are usage area of PaaS model. Usage Areas: Data and its Management Application Development, workflow etc... Directory Services. Security Services (Authentication, Authorization and single sign-on etc)

Infrastructure as a Service (IaaS): In this service delivery model the cloud


provider provide infrastructure (typically we can say this as platform virtualization environment) as a service. This service includes the Rental processing; Network Capacity; Storage and some other computational resources. The following are usage area of IaaS model. Usage Areas: Telecom Services. IT hosting and facility services. Securities, Servers, Networks, Mainframes and Storage etc

2.5

Deployment Models of a Cloud:


The cloud providers in the cloud computing architecture can deploy different types of

clouds as part of client requirement. Different type of clouds will accommodate different types of client needs. There are four types of basic and major clouds in the cloud computing architecture. Such as, Private Cloud: The private cloud is a cloud which has under leased or owned by the enterprise. A private cloud hosts on clients own network infrastructures own servers. And this cloud can be operated solely for that organization. And also it can be managed by that enterprise or by any third party and can also exist as off-premise or on-premise. The private cloud infrastructure offers many benefits of the public cloud like service based, cost effective and being elastic. Drawbacks: It is very difficult to access the cloud securely outside of the organizations LAN. It causes problems at production type of environments with the person who doesnt have experience.

Community Cloud: A community cloud is a cloud which supports specific


community and shared by multiple organizations for sharing concern (for e.g., security requirements, compliance considerations, mission and policy). And also it can be managed by those enterprises or by any third party and can also exist off premise or on premise. This cloud is also called as Media cloud. Drawbacks: The organizations cant keep the data secretly in this cloud deployment model. Public Cloud: Public cloud is a cloud infrastructure which is made available for the large scale organizations or general public group and also it is owned or leased by an organization which sells the cloud services. The public cloud infrastructure doesnt free

always. It is quite in expensive and only sometimes its free of cost. And also it doesnt mean that the end user information is visible publically. The public cloud providers typically deploy an access controlling service mechanism for their end users. Drawbacks:

Sometimes it is very hard to manage or maintain this cloud. Hybrid Cloud: Hybrid cloud is a cloud infrastructure which is a composition of
multiple clouds (i.e., Public, Private or Community) bound together by proprietary technology or standardized technology. It remains the unique entities and also enables the application and data portability. For example, cloud bursting. Drawbacks: Provide security to this type of cloud is challenge to the cloud providers because the hackers can hack the data easily in this infrastructure. And the cloud provider is required to answer the disasters of cloud.

Chapter-3 Taxonomy of a Cloud


3.0 Introduction
The taxonomy of a cloud clearly describes the portfolios of a cloud computing architecture. These portfolios are represented at cloud provider, service developer and client sides. So, as part of literature review, in this chapter I have described all about the classifications of cloud computing architecture and the standard relationship with tha t classifications.

3.1

Taxonomy of a Cloud
The Taxonomy of a cloud describes the classification of cloud computing architectures.

The bellow picture clearly explains the taxonomy of a cloud computing infrastructure.

Figure 3: Taxonomy of a cloud computing (opencloudmanifesto, 2009)

From the above figure we can clearly understood that the consumers of a cloud utilize the services which provided by the cloud. The Cloud Service Providers can manage the cloud

architecture and the service developers can develop the service for themselves. The lead roles in the cloud computing architecture are, Service Consumer Service Provider Service Developer Lets have a brief look at each of these lead roles in Cloud Taxonomy.

3.1.1 Cloud Service Consumer:


The cloud service consumer is the enterprise or end user or client who actually using the service and it doesnt matter whether it is SaaS, PaaS, or IaaS. From the figure we can clearly understood that the work flow of a service consumers. The client works with the programming interfaces and user interfaces depending on their role and the type of service which they are using. The client doesnt need to know about the cloud architecture as application usage even if some client interfaces look like any of the other application. The other client interfaces can provide administrative functions like managing cloud storage or starting and/or stopping the virtual machines. Depending on the applications the clients are developing they are writing the different application codes for that. The clients can work with contracts and the SLAs as well. Typically these types of things are negotiating through the human interventions between cloud provider and the cloud consumer. The reputation of cloud provider and the expectations of consumer are the key parts of this negotiation task.
Figure 4: Cloud Service Consumer (opencloudmanifesto, 2009)

3.1.2 Cloud Service Provider:


The service provider of a cloud delivers the cloud services to the client. The fundamental task of the cloud provider is subject to change depending on the type of the customer service.

Lets have a look at the fundamental task of cloud provider on each service delivery models of a cloud. For the SaaS (Software as a Service), the cloud providers installs, maintains and manage the s/w which the client need. In this service delivery model the cloud provider no need to own the physical cloud infrastructure in which the consumers s/w is running. Because in this software as a service model the client doesnt have permissions to access the infrastructure; only they can have the permissions to access the application which they need. For the PaaS (Platform as a Service), the platform of cloud infrastructure can be managed by the cloud provider because its just a typical framework of particular applications. The clients application dont access the cloud infrastructure lower the platform. For IaaS (Infrastructure as a Service), the cloud provider maintains the database, message queuing, storage or the virtual machines hosting environments or some of other middlewares. The cloud consumer will use that providers services as if they were a database, disk drive or machine, message queue but the cloud consumers cant access the hosting environments infrastructures.

Figure 5: Taxonomy of a cloud computing (opencloudmanifesto, 2009)

The above diagram represents the inner view of cloud service provider. In this illustration, the lowest layer in the middle be the hardware on top of which the entire cloud is based and the firmware. And the above layer is software kernel which consists of either virtual machine manager or the operating systems. The virtual machine manager is hosting the infrastructure which is beneath the cloud. The virtual images and the virtualized resources consist of basic services of the cloud computing architecture such as middleware, storage and the processing power. The virtual images of a cloud can be restricted by the virtual manager which contains both the images metadata which required managing the images and the images themselves as well. The right side stack or the last layer of the service providers console in the cloud computing architecture is management layer. This is the most critical part in clouds service providers console. In this management layer the low level consists of Monitoring, Provisioning and Metering. These three tasks of low level management layer determines that who using the services, up to what extent they are using and tracking status of the system and also its resources. At higher level, the management layer involves the Billing process, Capacity planning, SLA (Service Level Agreement) management and Reporting Services to the administrators. The most important and the vital part to the cloud providers is security. Security must be applied to all aspects of operations of the cloud service provider. The open security standards will also be applied to all operations of cloud service provider. A well rounded set of security standards simplifies the operations within the cloud service provider and also the interoperability with in the other cloud providers.

3.1.3 Cloud Service Developer:


The service developers of a cloud service provider create, monitor, and publish the cloud services. These are critically the applications of Line-Of-Business which delivers directly to the end user through SaaS model. The application which has returned at the PaaS and IaaS levels will be used by the developers of SaaS and the cloud service providers.

Development environments for the service establishment are subject to change. If the cloud developers are designing the SaaS application, then they most probably writes the code for the environment which is hosted by the cloud provider. In such cases the services publishing is deploying to the cloud service providers infrastructure. Whilst creating the services of a cloud provider, the cloud analytics involves in the remote debugging to test their services before published it to the clients. Once that cloud service is published then the analytics permit the developers to monitor the activities (i.e., performance, etc) of that developed service and make the modifications if it is necessary.
Figure 6: Service Developer (opencloudmanifesto, 2009)

3.2

Cloud Computing Standards Relationships with Taxonomy


The cloud computing

architecture consists of four different types of standards which will affect the clouds use case scenarios. Each of these standards will have a major impact on the each service type of a cloud,

between cloud and enterprise and also within an enterprises private cloud. (Jhon et al, 2009).
Figure 7: Standards Taxonomy Types of Standards (opencloudmanifesto, 2009)

3.2.1 Standards Across The Cloud Service Types


After cloud computing architecture became more common, the applications likely using the different cloud service types. An application in the cloud may use the message queuing mechanism, storage service, and also managing (Start/Monitor/Stop) the VMs which running in

the cloud. The standards in the cloud describes that how these different services types work together to provide a value. (Jhon et al, 2009).

3.2.2 Standards Within The Cloud Service Types


The open standards in the cloud make the services possible to avoid the cloud provider lock-in within each cloud service types (i.e., SaaS, PaaS or IaaS). In the clouds SaaS model the open standards will be applied at an application layer. But in this service a few standards work as cloud specific. For example, for document portability the application of the clouds word processing should support the standards. But in the application of word processing, the requirements for these standards support nothing to do even that application is runs in cloud. (Jhon et al, 2009). In the clouds PaaS model, a lot of platforms which provided in cloud will be the application frameworks. These application framework types typically provide the regular services such as databases, client interfaces and the storage. But these are all accessible throughout that frameworks APIs. (Jhon et al, 2009). In the clouds IaaS model, to work with Cloud service DBs a standard APIs set would permit the applications of cloud to work with the data from cloud vendors. These general API gives freedom to users to move to any other cloud service providers DB without any major changes. And also it makes easy to incorporate the new data sources among the existing applications. The common Application Programming Interfaces (APIs) for the other cloud service architectures such as map reduce, message queues or storage can provide the similar benefits, and also the common formats for the data and the data interchange. In case of VMs a common VM format is the crucial one. The clients should take a virtual machine built and it can be deployed with the one other cloud service provider and also deploy with another cloud service provider without any modifications. (Jhon et al, 2009).

3.2.3 Standards Between Enterprise and Cloud


The enterprise architectures (like Java, EE etc) wont go anywhere even as the cloud computing emerges. The standards of cloud computing defines that how the application of enterprise communicates with the resources like cloud message queuing and the cloud database would enable all of these applications to use in the cloud services without or with a little changes. (Jhon et al, 2009).

3.2.4 Standards Within the Enterprise


The standards within the Enterprise will determine by so me of the requirements such as audit ability, interoperability, management and security, and also these will be built upon the cloud standards which applied between the cloud and the enterprise. For all these standards the enterprise is interact with the some of the public, hybrid and the private cloud combinations.

3.3

Application P rogramming Interface (API)s


The primary and major mechanism to build the solutions of cloud computing is APIs

which provided by the cloud providers. The following are the four different levels to work with the cloud APIs and these are split into the five different categories. (Lizhe, 2011)

Levels of Application Programming Interfaces (APIs)


There are four basic and different API levels. Each of these levels requires the cloud service developers who focus on the data structures and the different tasks. The Wire (Level 1): At this level-1, the cloud developer directly writes to requests wire format. If the cloud service is on REST-based then the cloud developer creates and opens appropriate internet protocol (i.e., HTTP) headers and also it creates requests payload. This REST-based service returns the data with appropriate protocol (HTTP) response code. Due to straight forward behavior of this REST-based service, this level is efficient to write the code. (Jhon et al, 2009).

For SOAP-based services, the cloud developer will creates SOAP environment, and attach appropriate headers and fill the body with payload data. The SOAP (Simple Object Access Protocol) cloud service is respond with only SOAP envelope which consists of request results. The working progress with clouds SOAP service needs XML parsing envelope content. So for that reason maximum of SOAP services of a cloud will be invoked with the high level APIs. (Lizhe, 2011) Language-Specific Toolkits (Level 2): The Language Specific Toolkits are the things which are using at this level 2 by the cloud developers for REST and/or SOAP requests. Although the cloud developers still focused on structure and format of the data which going across the wire, then many more details (for example, handling the calculating signatures and response codes) will be handled by the these toolkits. (Lizhe, 2011) Service-Specific Toolkits ((Level 3): To work with some particular cloud computing services the cloud developers are using high level toolkits. When the developer works at this level, he will be able to focus on processes and objects of the business. A cloud developer must be more productive while focusing on processes and data which belong to the company instead of focusing on wire protocol. (Lizhe, 2011) Service-Neutral Toolkits (Level 4): The Service-Neural Toolkit is the APIs highest level in the cloud architecture. While working in this level the cloud developers will use some common interfaces to several multiple cloud providers. Unlike the previous level (Level-3) the cloud developer doesnt worry about the cloud services with which they are working.

Categories of API:
The cloud programming interfaces are divided into 5 categories. Those five major categories are categorized by the levels of APIs of cloud programming interfaces. Each of these levels requires the cloud service developers who focus on the data structures and the different tasks. Ordinary Programming (Category 1): The general APIs in the real world are PHP, JAVA, C#, VB etcIn this category no particular API is cloud specific.

Deployment (Category 2): The programming interfaces will be used to deploy the Cloud applications. The cloud packing technologies includes some of the traditional packaging mechanisms (i.e., .net assemblies (.dll& .exe) and WAR/EAR)). (Jhon et al, 2009). Cloud Services (Category 3): As we discussed earlier, the APIs of cloud services can be the either service- neutral or service-specific. These cloud APIs are again divided into the subcategories for cloud DBs, cloud message queues, cloud storage services and the other services. The APIs aware that the cloud developers are using cloud while he/she writing the code using cloud services. (Jhon et al, 2009). Infrastructure and Image Management (Category 4): The APIs are used to manage VM infrastructure and Images in detail. And also these images support the deploying, uploading, restarting, deleting, starting and stopping the images. The APIs of infrastructure management controls node management, load balancing, firewalls and network managements in detail. (Jhon et al, 2009). Inte rnal Interfaces (Category 5): For internal interfaces the programmings are interfaces the clouds different parts. These will be used to change the cloud vendors at storage layer in the cloud computing architecture. (Jhon et al, 2009).

3.4

Roles of a Cloud Developer


After we learn about the cloud computing and before we know about the security area of

a cloud we need to have look at the roles and responsibilities of cloud developers. The requirements of the cloud services and APIs are subject to change from one aspect to other. Below are the roles of a cloud developer along with the API categories what they use: Application Developer: These developers write the traditional applications which are useful to cloud. And also these application developers use category 1 and category 3 APIs. Client Application Developer: These client application developers write the client applications which are cloud-based. And also these developers use category 3 APIs.

Deployers: The Deployers in the cloud architectures are deploy, maintain and package the applications. At this aspect, the life cycle management will be concerned as well. These developers use category 4, 3 and 2. Cloud Providers: These developers are work with cloud infrastructure und erneath the cloud offerings and also these developers use category 5 APIs. Administrators: These developers work with the multiple level applications including the infrastructure management and deployment. And also these developers use category 4, 3 and 2 APIs.

Chapter-4: Cloud Data Security


4.0 Introduction
Till now everything about cloud computing has been discussed. In this same manner in this chapter it needs to discuss about the Cloud data Security and its issues. Our project is DATA CONTROLLING IN CLOUD. Its a management and the security issue. So thats why we need to discuss everything about the Cloud Computing and also its security issues. So in the above chapters we already discussed about Cloud Computing (Internally about every management issue), now we are going to see the Cloud Security and its Issues.

4.1

Security Concern
Security is a major concern of Cloud Computing because both the program and customer

data are residing at Cloud Providers premises. More over in Open Systems Architecture, security is an important factor (Saurabh, 2009). The bellow figure explains rating of different areas of a cloud with respect to on-demand model.

Figure 8: Cl oud Computi ng Scale (Saurabh, 2009)

4.2

Dangers and The Vulnerabilities of Cloud


The Security factor in the cloud is to save both the program and the data from the dangers

and the vulnerabilities. The bellows are some of the dangers and the vulnerabilities of a cloud computing architecture. (Saurabh, 2009)

Dangers
Privacy Loss Disrupts Services Information Damage Theft of Information Vulnerabilities Hostile people will give instructions to the good programs of a cloud Hostile programs Bad people Eavesdropping, Daniel of service or corrupting on network communications. (Saurabh, 2009).

4.3

General Cloud Security Requirements


We already know how security is the most expensive and worried thing of a cloud

architectures. The cloud providers are making sure that the cloud architecture meet the security requirements. The following are four common types of security requirements in the cloud computing architecture.

Confidentiality:
The confidentiality means the cloud provider needs to ensure that the information must not disclose from unauthorized people, devices or processes. That means not all the company owned data must be made accessible to the public. If the protection of data confidentiality fails that leads to disastrous of an organization. The data confidentiality should satisfy the following conditions simultaneously:

The Cloud Service Provider must know where the clients confidential information is located at their Cloud Computing Architecture Systems. The cloud Service Provider must have the privilege to collect and access the clients confidential information in Cloud Architecture Systems. The Cloud Service Provider must understand about such things they are the types of data, format of data and interfaces and functionalities of the application by using the data. Hence, if the cloud provider satisfies the three conditions which we mentioned above then we can say that that Cloud Service Providers maintaining the confidentiality of the data. (Saurabh, 2009)

Availability:
Availability means the Cloud Provider needs to ensure that the processing of information resources is not made inaccessible by the malicious action. The cloud well publicized outage incidents are Gmail One day outage on October, 2008. (Chow R, et. al [2009]) Flexi Scale Over Eighteen hours outage in 31 st October, 2008. (Chow R, et. al [2009]) Amazon S3 Over seven hours downtime in 20 th July, 2008. (Chow R, et. al [2009]) Availability Factors: The following are factors of Cloud Availability. Such as Uptime : As with the concerns of Traditional Security, the Cloud Provider argues that their cloud architectures server uptime will be compared well with Clients own data centers availability. Computational Integrity Assurance: It means to make sure that the organizations assure that the Cloud Providers are faithfully run hosted application and gives the trusted results. Stanfords project Folding@Home is the best

example for this because this project giving same task to the multiple clients for trusted result. Single Point of Failure: The cloud services may not give the more availability. There are plenty of Single Point Failures.

Integrity:
Integrity means ensuring of the information which held in the system must have a proper intended information representation and also that has not been done any modifications by any unauthorized users.

Non-Repudiation:
Non-Repudiation means ensuring that the Cloud Provider and consumer agreements must be made electronically, because it will prove that the agreement has been made.

4.4

Security Levels and Questionnaire


In the architecture of Cloud Computing we need to provide the security at some levels.

Those levels are all listed in the billow. such as, Server Access Security. Database Access Security. Internet access security. Program Access Security. Data Privacy security.

Questionnaire:
Cons umers View: The cloud consumer before get the service deployments from the client, thinks like this in a broad level How secure is the code? How secure the data is?

Most Ans werable Questionnaire of a Cloud Provider: The cloud Providers must answer the following questions if the client needs that, How secure the data at Network Layer? How secure the data at Physical Layer? How trust is the Cloud Service Providers Encryption scheme How safe is the data from the Natural Disasters?

In the above questionnaire everyone can answer the last question. To secure the data from natural disasters, The Cloud Provider should distribute the Physical location across the world. And also the Cloud Provider should store the data redundantly in multiple of physical locations.

4.5

Data Centre Security


Nowadays the cloud providers not only secure the data flow at the data centers. Because

providing security at the data centers are not small issue. Its an issue of entire organization and each and every department issue. The following are some of the issues to secure the data centers. All the electronic and Physical access of data centers by the employees should be audited and logged routinely. If an employee has no longer business need for accessing data center in his privileges then it should be revoked immediately. The professional security staff at the data centers utilizing the state of the systems art intrusion detection, video surveillance and the other electronic means. By the Audit tools, the users can determine easily how the data is protected, verify policy enforcement, used and stored. (Saurabh, 2009)

4.6

Data Location
The location of data is a legal issue of cloud providers. The entire cloud development

team must aware of where the data is located? And how secure it is? The following are the some concerns about the location of data. And also the billow figure illustrates the relationship between data and the security policies. The data should be processed and stored only in some specific jurisdictions which defined by the user. When the client uses the cloud, the user probability dont know where the data is located/hosted and in which country it going to be or will be stored? The data-centered policies will be generated when the client provides sensitive or personal information that has been travelled with that data all the time to make sure that the data is accessed only in accordance and also with the policy. (Saurabh, 2009) The Service Provider should make some contractual commitments on behalf of the clients to obey the local privacy requirements.

DATA CLOUD SECURE P OLICIES

Figure 9: Relationship between data and policies (assumption)

4.7

Data Backups
The backing up of data at the data centers is a sensitive issue of cloud computing

architectures. The cloud data center management making sure of clients legal issues and the security policies of cloud. The bellows are some of the tasks regarding to backup the data. Such as, Administrators control on Databases.

The cloud provider should redundantly store the data in multiple physical locations. The service provider doesnt perform the backing up of data while the running of a program is on progress

4.8

Sanitization of Data
The word sanitization is a process of irreversibly, permanently and deliberately

destroying or deleting the data from the storage devices. The billows are the some of the key issues of cloud data sanitization. Some type of data sanitization practices to the cloud service provider to implement for retiring and redundant storage devices when these storage devices are thrown out of service or retired. What will happen when the data has passed from the use by date of its user in cloud computing environment? (Saurabh, 2009)

4.9

Issues of Host Security


Host security is an important security issue of cloud computing management.

Unfortunately if anything goes wrong with host security then the devices might attack by the attackers or the unknown users. The following are some of host security issues of cloud computing architecture. The Host runs the cloud service provider jobs, but some of these jobs might contain the worm or viruses which can cause of system destroy. From the Malicious Users. Possibility: A set of trusted users is defined by the digital certification distribution, keys, passwords etc. and also the access control policies will be defined to permit the host resources.

Figure 10: Host Security (S aurabh, 2009).

Some of viruses and the worm create The issue of Job Starvation: If one job takes a lot of resource amount then it causes to resource starvation to other jobs. Ways to overcome: Reduction of priorities. Resources Advanced Reservations.

4.10 Information Security


It means the Security which belongs to information exchanged between Users and Hosts or between different Hosts. The following are some of the information security issues of cloud architecture. Such as, These Security issues are pertaining to the issues concerning Delegation and Single Sign on, Authentication and Secure Communication. The secure communication of information security issues containing those security concerns which arise while the communication is under progress between two entities. And also these include integrity and confidentiality issues. We already known about the integrity and confidentiality in the above sections.

Possible ways: X.509 certificates, Public Key Encryption and the SSLs (Secure Sockets Layers) enable the communication and authentication over the computer networks. (Saurabh, 2009) The bellow figure clearly describes information security issues on the cloud computing architecture.

Figure 11: Information Security (Saurabh, 2009).

4.11 Network Security


Network security is the infrastructural security of a cloud computing architecture for public as well as private services. The cloud providers data security is also burden to network security management i.e., network security is not only for devices security that is also take care of data security.

DOS (Denial of Service): By the DOS attack the entire network and the servers will be brought down with huge amount of the network traffic and also the users will be denied to access the internet based services. QOS Violation: It causes to dropping the packets, through congestion, resource hacking, delaying, jitter, or latency. Like the Routing table Poisoning, DNS Hacking, XDOS attacks. IP spoofing: The term spoofing is a creation of the TCP/IP packets by using others IP address. Possible way: Infrastructure wont allow the instances to send the traffic with MAC or Source IP address or any other. Man in Middle Attack: Use SSL always to over this type of attacks. ARP (Address Resolution Protocol) Cache Attack: A Computer sends some ARP broadcast requests to find the MAC addresses which associated with some IP addresses. An attacker can sniff the victims network packets by his ARP packet spoofing on his Ethernet network by sitting at same LAN (i.e., Ethernet network). Port Scanning: To allow the traffic from any of the source to particular port when the user configures security group, then that particular port can be vulnerable to the port scan. If the port scanning of a network is detected then it should be blocked or stopped.

4.12 Virtualization Security Issues


Virtualization security is also one of the shake up security concern for the cloud providers, because it is not only for a single client. This phenomenon is designed for multiple OS in a single OS. The following are the some of the issues of virtualization security. The virtualization type providers are using the full system or Para virtualizations. Administrators control on the Guest OS and the Host OS. Present VMMs doesnt offer the perfect isolations: In the network multiple bugs have been detected in all the popular VMMs that permit to escape from the VM.

Instance Isolation: It ensures that several instances which running at same machine will isolate from each other. The monitoring of VMs must be root secure, that means no privilege levels within the environment of virtualized guest allows interference with host system.

4.13 Vulnerability in the Virtualization


In all the virtualization software some vulnerabilities of cloud security have been found, which is exploited by the local users, malicious users to gain escalated privileges or to bypass the obvious security restrictions. For example: If any vulnerability is detected in the shared folders mechanism of VMware, that permit the guest users system to write and read access to any Host file systems portion and also it can includes the security sensitive files and the system folders. The vulnerability in MS Virtual Server and MS Virtual PC could allow the user of Guest OS to run/debug the code on the other Guest or Host OS. The vulnerability of the Virtual Server and the Virtual PC could allow the privilege elevation. The vulnerabilities in the Xen devices will be caused due to the error of input validation in Src/pygrub/tools/GrubConf.py. This will be exploited by the Guest domains Root users to execute the arbitrary commands in the domain 0 through special crafted entries of grub.conf while the booting of Guest system is going on.

4.14 Risk Prevention at VMM


To prevent the risk at Virtual Machine Manager, there are some properties that the virtual machines must follow. Such as Inspection: The Virtual Machine Manager has an access to all VM states like all memory, CPU state (Ex: registers) and the state of all I/O devices such as registers I/O controllers state and the storage devices content. So that the VMM can monitor the VM. Isolation: The Software which is running in the VMs cannot modify or access the software which is running in a separate VM or in VMM.

Inte rposition: The Virtual Machine Managers need to interpose the operations of VM (Ex: instructions of executing privileged). For example if the code which running on the VM can attempt to change/modify the given register. The figure clearly explains the hierarchy of risk protection at virtual machine manager. Need an Anti-Virus layer to protect and control the Networking CPU and Memory Storage Procession execution Credential Management: This
Figure 12: Risk Protection (Saurabh, 2009).

management system can manage and store the credentials of users and some

variety of systems to access those according to the requirements. Management Related Issues: The Management is an important thing as the cloud service is heterogeneous by nature and also it may consis ting of some multiple entities, users, components, domains, stake holders and policies. Safe and secure credentials storage is as important as management task.

4.15 Cloud Encryption Scheme


Encryption is a process of converting the messages from plaintext to cipher text and also it must be decoded back into actual message. In this scheme an encryption algorithm contains a key for the data encryption and the decryption along with it. Nowadays we are having several types of encryption mechanisms which can form on network security basis. And also these schemes are always based upon stream and block ciphers. The cloud service providers, before using the encryption mechanisms keep the questions below in their mind. Such as, What types of algorithms are used for to secure the data?

Is there any possibility for all my data encrypted fully? Who maintains issues and holds the keys? Dangers with Encryption: Encryption makes the availability complicate. Encryption accident incidents can make the total data unusable. Possible ways: The cloud service providers make sure and must provide the evidence that the encryption mechanisms were tested and designed by the well experienced specialists. The below diagrams illustrate one of the major encryption/decryption type that is Symmetric Encryption/Decryption process scheme.

Figure 13: Symmetric encryption/decryption process (Assumption)

The below diagrams illustrate one of the major encryption/decryption type that is Asymmetric Encryption/Decryption process scheme.

Figure 14: Asymmetric encryption/decryption process (Assumption)

Sample Encryption/Decryption code in C#:


The below Code is encryption/decryption code in .NETs c# language.

public string EncryptString (string xmlString, intdwKeySize, string inputString) { RSACryptoServiceProviderrsaCryptoServiceProvider RSACryptoServiceProvider( dwKeySize ); Handlers rsaCryptoServiceProvider.FromXmlString( xmlString ); intkeySize = dw KeySi ze / 8; byte[] bytes = Encoding.UTF32.GetBytes( inputString ); intdataLength = bytes.Length; intmaxLength = keySi ze - 42; int iterations = dataLength / maxLength; StringBuilderstringBuilder = new StringBuilder(); for( inti = 0; i<= iterations; i++ ) { byte[] tempBytes = new byte[(dataLength - maxLength * i>maxLength ) ? maxLength : dataLength - maxLength * i ]; = new

// TODO: Add Proper Exception

Buffer.BlockCopy (bytes, maxLength * i, tempBytes, 0, tempBytes.Le ngth ); byte[] encryptedBytes = rsaCryptoServiceProvider.Encrypt (tempBytes, true ); stringBuilder.Append( Convert.ToBase64String( encryptedBytes ) ); } return stringBuilder.ToString(); }

public string DecryptString( string inputString, intdwKeySi ze, string xmlString ) { RSACryptoServiceProviderrsaCryptoServiceProvider RSACryptoServiceProvider (zw KeySize ); Handlers rsaCryptoServiceProvider.FromXmlString( xmlString ); int base64BlockSize = ((dwKeySize / 8 ) % 3 != 0 ) ? ( ( ( dwKeySi ze / 8 ) / 3 ) * 4 ) + 4 : ( ( dw KeySi ze / 8 ) / 3 ) * 4; int iterations = inputString.Length / base64BlockSize; ArrayListarrayList = new ArrayList(); for( inti = 0; i< iterations; i++ ) { byte[] encryptedBytes = Convert.FromBase64String (inputString.Substring (base64BlockSize* i, base64BlockSize)); Array.Reverse( encryptedBytes ); arrayList.AddRange (rsaCryptoServiceProvider.Decrypt (encryptedBytes, true)); } return Encoding.UTF32.GetString (arrayList.ToArray (Type.GetType = new

// TODO: Add Proper Exception

("System.Byte")) as byte[] ); }

Proposed Cloud Architectural Design


(Chapter - 5)

Chapter-5: Proposed Cloud Architectural Design


5.0 Introduction

In this chapter I have described about the proposed cloud architectural design. To illustrate some of the concepts and workflow, the Bonita Open Solutions 5.5 designs diagrams are used. After an in-depth investigation on the cloud data security this architectural designed process has been designed. The billow is the proposed cloud architectural design.

Architecture of our Proposed Cloud Data Control Process


Start Client

Client Sends Data request to Cloud Request passes through Data check-In to Cloud Request goes to transmission mode after Check-In

Cloud Management Team

Data Status Division

Data Centre / Security Pool

Data in Use

Data at Rest

Data in Motion Raise Alarm

Data Security Area

Data Center Updation

Compose Rejection Msg to Client

End

Intrusion Rejection Process

5.1

Design Concepts of Proposed Cloud Architectural Design


The above proposed cloud architectural design process can be explained by some of the

concepts. Those concepts are as follows, 1) Client 2) Cloud Provider. a) Cloud Management Team. b) Data Center. c) Intrusion Rejection Process

5.1.1 Client:
The Client of Cloud Computing contains a computer software or/and a computer hardware which dependents on cloud computing architecture to support the application deliveries, or which designed specifically for cloud service deliveries. A Client of Cloud Computing Architecture is an interface of common cloud user through the web browsers or thin terminals. According to our proposed system the client just send a request to the cloud then the remaining process is under take care of cloud service provider who consists of Cloud Management Teams, Data Centers/Security pools and the Intrusion Detection Mechanisms. The bellow diagram represents the Data Request flow from Client to Cloud.

Figure 15: Data Request flow from Client to Cloud (Assumpti on Design using Bonita)

5.1.2 Cloud P rovider:


Cloud provider is the one who offers the Cloud Service Delivery Models to Client through the internet. According to our proposed Cloud Data Control Process contains the following sections for a smooth and secure flow of data. Cloud Management Data Center / Security Pool Intrusion Detection

5.1.3 Cloud Management:


The cloud management is responsible for delivering all the cloud models and its services. And this team is responsible to provide the security to the data flow of a client via the internet and also this team is responsible for the security of data at data centers. The bellow diagram represents the Request flow through the clouds Management Team and the Its Security Pool.

Figure 16: Cloud Management Team and the Its Security Pool (Assumption Design using Bonita)

At this Client Management Team and its Security Pool section of a cloud provider the data request which comes from the client will goes to cloud data check- in block. In this block all the data check-in processes will be performed. If any intrusions/viruses/unsecured data is found then it goes to intrusion detection section. Then the Cloud Management team will be make sure and will be aware of that content. After all the check-in process is complete then the request goes to DMT (Data Mode for Transmission) section. Here the request will wait for the response to

find the data mode which is in the Data Centers. Then the next task is under take care of Data Centers and its Security Pool Management Team. All of this process will be done with in a fraction of milliseconds, because the cloud provider consists of a lot of computational power.

Data Centers /Security Pool: The Data Centers are the essential asset of Cloud Computing
corporations, these all connects to all applications, storage services and servers. The business rely on the cloud data centers supports the business values and operations and drive maximum efficiencies. The data centers are playing key roles that needs to managed and planned very carefully to meet applications and the users growing performance requirements/demands. The data center architectures proposes technologies, practices and products which helps to data center engineers and management team who is responsible to answer the business goal requirements. The bellow diagram represents the Data Center over view according to the proposed cloud architectural design network .

Figure 17: Data Center over view according to proposed network (Assumption Design using Bonita)

In this Data Center and its security section of our proposed network the data request which finish all the data check- inns and waiting for the data center response to choose the way to data security area will reach the data status division. Here our architecture concept is Divide the data which is in the data centers in three possible ways such as, Data in Use Data at Rest Data in Motion

The servers which are at the data centers are connected in clustering technique. These are the intelligent servers these having the sense to find any traffic at Cloud Managements data Transmission Mode. After that it responds immediately and gives the appropriate direction (Data in Use or Data at Rest or Data in motion) to that request. By this data division we can get the more and more data requests from the users to the data centers and also we can respond immediately.

Intrusion Detection: The intrusion detection section is used to intimate the cloud
management team, data centers and also its security pools about the intrusions by raising the alarms. The dangers which will happen by the intrusions are scalable (1-5, here 1is ignorable danger and 5 is most danger). In this section the by the orders of management team the rejection and warning messages/e- mails will be composed to send the client. The bellow diagram represents the Intrusion Rejection Process of proposed cloud architectural design network.

Figure 18: Intrusion Rejecti on Process (Assumption Design using Bonita)

5.2

Advantages of our Proposed Cloud P rocess Design


After successful design of proposed cloud architectural design many of the advantages

are found out. The billows are the advantages of proposed cloud architectural design are explained. Such as, It helps the client to quick access of the applications whatever he wants, without any installation. By using the internet access client can access rapidly any of his personal files at any computer.

The cloud computing offers more efficient and secure computation to the users by bandwidth and processing, centralizing storage system, and memory. This proposed cloud process design can improve the performance of cloud computing architecture. This process gives the clients to most secure way of computing. The cloud providers can control the huge data by this design.

5.3

Data Flow Diagrams


The data flow diagrams in this document represent the process of cloud data flow. These

client data request in the proposed system communicate with the cloud provider in the form of request and reply methodology. In short the diagrams of data flow are clarifying the data movements within the processes. In the data flow diagrams it is clearly specifies that the proposed systems input and the output. The bellow data flow diagram clearly explains the data flow of our proposed cloud Process design in an efficient data controlling idea (Opencloudmanifesto, 2009).

Use Case Diagram:


In these use case diagrams, generally there are two fundamental units; such as 1) the ellipse 2) the actor. Basically the ellipse of the use case diagrams explains the communication process of the actors performance details with the proposed system which is being designed. And also the use case diagrams clearly signify the proposed systems succeeding associations. The actor represents an individual or the thing which is communicating (Opencloudmanifesto, 2009). Use case Diagrams: The bellow diagrams are the use case diagrams of the proposed cloud architectural design from client and Cloud management side views.

Figure 19: Use Case Diagram from Client Si de

Figure 20: Use Case Diagram from Cloud Management Side

Sequential Diagrams:
The sequence diagrams are very useful to represent the proposed systems communication which take place among the objects, and in a sequence order which the communications take place. The Sequence diagrams are very helpful to the organizations staff to understand the work flow and an order in which the organizations activities are operated (Opencloudmanifesto, 2009). The bellow diagram is the sequential diagram of the proposed cloud architectural design process.

Figure 21: Sequenti al Di agram of Proposed Cloud Architectural Design

Business Process Modeling for Simulation of Cloud Data Control Architecture and Workflow using Bonita Tool
(By Using Bonita Open Solution 5.5) (Chapter- 6)

Chapter-6 Business Process Modeling for Simulation of Cloud Data Control Architecture and Workflow using Bonita Tool
6.0 Introduction

In this chapter I have described about the Business Process Modeling for Simulation of Cloud Data Control Architecture and Workflow. To explain workflow of proposed cloud architectural design the Bonita Open Solutions 5.5 has been used (See Appendix-A for more information about BOS 5.5). This tool is very useful for business process model design simulation of proposed cloud architectural design.

6.1

What is a Business Process?


The term business process is a set of activities perform a particular business outcome for

a specific client or market. It exhibits a strong progress on how the business work is going on /done whining the organization. And also it is in a contrast to the products which focus on what. A business process is a definite work activities ordering across the place and time, with a beginning, clearly defined of input & outputs, and an end. The Business of an organization processes as input to output transformations. The bellow diagram is the input and output transformations of business process.

Input

Output

Figure 22: Input and Output Transformations of Business Process

6.2

Business Process Modeling Assumptions

The business process modeling of proposed architectural design having some of assumptions. Those assumptions are as follows, Sending Data Request from client side is as a human task. Data Check- in process at cloud provider side is service task and it a connector between data mode transfer service and the client. The remaining all the tasks are service tasks except alarm (its an event) and compose rejection Mail/Msg task (its an automation process). Before we run process simulation we need to define the process, manage the resources, and load the profiles to get the immediate reports on project process efficiency for rapid identification of bottlenecks. The simulation process duration is 2 days 13hrs. 5 min for all the tasks.

6.3

Business Process Modeling Environment

Figure 23: Bonita Studio Version

Figure 24: Bonita Studio Futures

6.4

About BOS-5.5
The business process model design tool which is used in this project is Bonita

OpenSolution-v5.5 (BOS 5.5).Bonita Open Solutions 5.5 is not only for modeling this can be used for modeling, running and debugging the process, simulation of a process. Coming to business processing section of Bonita Open Solutions 5.5, it has a range of tasks to develop the business process modeling (See Appendix- A). Those tasks are Human Tasks: These are also called as user/client/end user tasks. These tasks need an involvement of an actor. Service Tasks: These are the tasks which processed whole the process by the execution engine of Bonita. Previously these tasks are known as automatic tasks. Call Activity: It means an element represents the other process task. The sub process of task runs within the parent process cycle, but it should be defined in a different pool. The call activity runs the sub process automatically when the process has been reached and also it has been returned to the parent sequence process as well.

Script Task: The script tasks are the Service Tasks with some script. These script tasks execute when a task reached the process. By implementing the connectors, we can define the script for execution (and also when the execution should be start). Abstract Task: These are the undefined tasks of a business process model. Abstract tasks required to change one of the previous tasks of a process while execution is in progress. Send Task: A Send Task of a process sends messages to the further sections when the task reached the process. Receive Task: A Receive Task of a process waits to receive messages from the previous sections when the task reached the process. The catch message of receive task is used to catch the specific messages for a specific tasks. (See Appendix-A) These tasks are useful to design complete and suitable business process modeling. And also there is a simulation environment to simulate the designed business process model. This BOS 5.5 has a GUI (graphical user interface) which the results of different processes can be viewed. And also it has an environment called white board is used to design required business process models. This Bonita Open Solutions 5.5 consists of many tools (like object palette, over view palette, general options palette and etc) which improve the user experience of desired proposed business process design. We need a browser to get final output of the processes like run and debug. The final simulation process graphs are displayed in another GUI tab. To run the simulation in the Bonita we need do three major steps such as, Define the Process. Manage the Resources Load profiles After only doing all of these we can get immediate reports of the designed process. And also every Bonita user make sure while designing the business process model that, the process contains proper tasks or not. (See Appendix-A)

6.5

Cloud Business Process Design


The billow design is the over view of business process model design of a cloud according

to our data controlling idea implementation.

Figure 25: Business Process Model Design of Data Controlling in Cloud in Bonita

The above figure is the Business Process Model Design of our dissertation (Data Controlling in Cloud) in Bonita Open Solution 5.5. It consists of two sections, such as 1. Client 2. Cloud Provider. a. Cloud Management Team. b. Data Center. c. Intrusion Rejection Process The description and process of each and every task of above is already explained in the chapter-5 as Design Concepts of Proposed Cloud Process.

6.6

Bonita Simulation Results Regarding to the Proposed Design


As I mentioned in advance about Bonita open Solutions 5.5, we need to look at some of

the business process modeling results such as, Load Profiles, Execution Times, and Execution Time by Instances, Cumulated Time, Waiting Time, Cloud Provider Consumption, Cost and Utilization. We have to measure each and every task of our proposed business process design.

6.5.0 Cloud Provider Simulation Details:


The bellows are the simulation details of proposed architectural design process by using BOS 5.5. o Simulation Start Date: 19/07/2011 01:35:00 o Simulation end Date: 30/07/2011 03:45:00 o Simulation Duration: 10 days 14 hours 10 minutes o Execution time of Each Task: 22 seconds o Number of simulated Instances: 100

6.5.1 Load Profile:


This load profile describes the work load activities of a cloud network which arisen within a particular interval. The statistics of load profile gives an idea of cloud providers workload during that particular interval. However, these load profile doesnt indicate that the devices of a network are working or not and also it doesnt indicates that what is in the database devices.

Figure 26: Load Profile

The above graph shows the load profile of our proposed cloud network (Data Controlling in Cloud). It represents the injection load profile which is used for the simulation of proposed phenomena. The default number of cloud instances in Bonita Open Solution 5.5 is 100.

6.5.2 Execution Time:


The execution time is defined as the time which spent by the cloud systems to process a task. It includes the execution time of a task and services in which that task is depending on. In short, the execution time a time between starting and ending point of a task i.e. the time it takes to execute a task. The bellow graphs are the execution times of each and every instance of our proposed network. According to our proposed process model there are two types of execution times such as, Instances Execution Time Represents the execution times of simulated process instances through the total time span. Execution Times by Instance

Represents the key execution times of a process instance regarding all the executed instances.

Cloud Provider Execution Times: The bellow graph describes the Cloud Provider Instances Execution Time in hours.

Figure 27: Cloud Provider Instances Execution Time

The bellow graph describes the Cloud Provider Execution Times by Instance in hours.

Figure 28: Cloud Provider Execution Times by instances

Data Check-In Execution Times: The Data Check-In section is one of the important task in the cloud service area, because here is place to check all the data by cloud management team to make further processes i.e., all the data which comes from the clients/consumers must check at this place of cloud providers area. The bellow graph describes the Data Check-In Instances Execution Time in hours.

Figure 29: Data Check-In Instances Execution Time

The bellow graph describes the Data Check-In Execution Times by Instance in hours.

Figure 30: Data Check-In Execution Time by Instance

Data Mode for Trans mission Execution Times: The Data Mode for Transmission service section is used to get status of the data from the data centers which the client request needs. By using these status informations the data request will chooses the appropriate path to get the results. The bellow graph describes the Data Mode for Transmission Instances Execution Time in hours.

Figure 31: Data Mode for Transmission Instances Execution Time

The bellow graph describes the Data Mode for Transmission Execution Times by Instance in hours.

Figure 32: Data Mode for Transmission Execution Time by Instance

Data in Motion Execution Times: The Data in Motion service section describes and intimate to client request at data mode for transmission that the data at the data center which the client request needs is in motion means that is under process. The bellow graph describes the Data in Motion Instances Execution Time in hours.

Figure 33: Data in Motion Instances Execution Time

The below graph describes the Data in Motion Execution Times by Instance in hours.

Figure 34: Data in Motion Execution Time by Instance

Data Security Area Execution Times: The Data Security Area section is major security task in the cloud service area, because this is the place to secure the traffic flow which is from the data centers and also the traffic flow which goes to the data centres. The bellow graph describes the Data Security Area Instances Execution Time in hours.

Figure 35: Data Security Area Instances Execution Time

The bellow graph describes the Data Security Area Execution Times by Instance in hours.

Figure 36: Data Security Area Execution Time by Instance

Raise Alarm Execution Times: This is a very useful service to the cloud providers that at any instances or at any particular time if the data is lost or if any intrusions are detected then this service will raise alarm to make the cloud management and security area alert. The bellow graph describes the Raise Alarm Instances Execution Time in hours.

Figure 37: Raise Alarm Instances Execution Time

The bellow graph describes the Raise Alarm Execution Time by Instances in hours.

Figure 38: Raise Alarm Execution Time by Instance

Compose Rejection E-mail/Msg Execution Times: This service is used to compose and send the rejection messages/e- mails to the client if any intrusions are detected by the client. The bellow graph describes the Compose Rejection Email/Msg Instances Execution Time in hours.

Figure 39: Compose Rejection E-mail/Msg to Client Instances Execution Time

The bellow graph describes the Compose Rejection E- mail/Msg Execution Times by Instance in hours.

Figure 40: Compose Rejection E-mail/Msg Execution Times By instances

6.5.3 Waiting Time:


The waiting time is an amount of time of a task which has been waiting in a ready queue. According to our proposed process model there are two types of waiting times such as, Cloud Provider Instances Waiting Time Represents the waiting times of simulated process instances through the total simulation time span. Cloud Provider Waiting Times by Instance Represents the key waiting times of a process instance regarding all the executed instances. Cloud Provider Execution Times: The bellow graph describes the Cloud Provider Instances Waiting Time in Hours . The value of graph represents that the cloud provider instances take minimum time which sets as default in the cloud service.

Figure 41: Cloud Provider Instances Waiting Time

The bellow graph describes the Cloud Provider Waiting Time by Instance in Hours.

Figure 42: Cloud Provider Waiting Times By instances

Data Check-In Waiting Times: Data Check-In instances Waiting Time represents the waiting time of simulated activity instances through the total simulation time span. The bellow graph describes the Data Check-In Instances Waiting Time in Hours.

Figure 43: Data Check-In Instances Waiting Time

Data Check-In waiting time by Instance represents the key waiting times of an activity instance regarding all the executed instances. The bellow graph describes the Data Check-In Waiting Time by Instances in Hours.

Figure 44: Data Check-In Waiting Time by Instance

Data Mode for Trans mission Waiting Time: The bellow graph describes the Data Mode for Transmission Instances Waiting Time in Hours . Data Mode for Transmission Instances Waiting Time represents the waiting time of simulated activity instances through the total simulation time span.

Figure 45: Data Mode for Transmission Instances Waiting Time

The bellow graph describes the Data Mode for Transmission Waiting Time by Instances in Hours . Data Mode for Transmission waiting time by Instance represents the key waiting times of an activity instance regarding all the executed instances.

Figure 46: Data Mode for Transmission Waiting Time by Instances

Data in Motion Waiting Time: The bellow graph describes the Data in Motion Instances Waiting Time in hours. Data in Motion Instances Waiting Time represents the waiting time of simulated activity instances through the total simulation time span.

Figure 47: Data in Motion Instances Waiting Time

The bellow graph describes the Data in Motion Waiting Time by Instances in hours. Data in Motion waiting time by Instance represents the key waiting times of an activity instance regarding all the executed instances.

Figure 48: Data in Motion Waiting Time by Instances

Data Security Area Waiting Time: The below graph describes the Data Security Are waiting Time in Hours. Data Security Area Instances Waiting Time represents the waiting time of simulated activity instances through the total simulation time span.

Figure 49: Data Security Area Instances Waiting Time

The below graph describes the Data Security Area Waiting Time by Instances in Hours. Data Security Area waiting time by Instance represents the key waiting times of an activity instance regarding all the executed instances.

Figure 50: Data Security Area Waiting Time by Instances

Raise Alarm Waiting Time: The below graph describes the Raise Alarm Waiting Time in Hours. Raise Alarm Instances Waiting Time represents the waiting time of simulated activity instances through the total simulation time span.

Figure 51: Raise Alarm Instance Waiting Time.

The bellow graph describes the Raise Alarm Waiting Time by Instances in Hours. Raise Alarm waiting time by Instance represents the key waiting times of an activity instance regarding all the executed instances.

Figure 52: Raise Alarm Waiting Time by Instances.

Compose Rejection E-mail/Msg to Client Waiting Times: The bellow graph describes the Compose Rejection E- mail/Msg to client Waiting Times Waiting Time in Hours, Compose Rejection E- mail/Msg to client Instances Waiting Time represents the waiting time of simulated activity instances through the total simulation time span.

Figure 53: Compose Rejection E-mail/Msg to client Instances Waiting Time.

The below graph describes the Compose Rejection E- mail/Msg to client Waiting Time by Instances in Hours. Compose Rejection E- mail/Msg to client waiting time by Instance represents the key waiting times of an activity instance regarding all the executed instances.

Figure 54: Compose Rejection E-mail/Msg to client Waiting Time by Instances.

6.5.4 Cumulated Time:


The cumulated time of a cloud provider represents the cumulated execution time and also the waiting time throughout the simulation. According to our proposed design for every 100 load profiles of a client the cumulated time is as follows. And this time is varying from client to client and also depending on the instances.

Figure 55: Cloud Provider Instances Cumulated Time

6.5.5 Cloud Provider Consumption:


The Cloud Provider Consumption graph represents the number of resource instance used within the total simulation time span. The bellow graph describes the consumption of Cloud Provider.

Figure 56: Cloud Provi der Consumpti on

The Cloud Provider Consumption by instance graph represents the major figures of resource consumption for a process instance regarding to the entire executed instances. The bellow graph describes The Cloud Provider Consumption by Instance.

Figure 57: Cloud Provider Consumption by Instance

The Cloud Provider total Consumption graph represents the resource consumption of entire cloud service. The graph below describes the Cloud Provider total Consumption.

Figure 58: Cloud Provider Global Consumption

6.5.6 Cloud Provider Cost Estimation:


The Cloud Provider Cost estimation graph represents the cost of resource through the total simulation time span. The below graph describes The Cloud Provider Cost.

Figure 59: Cloud Provider Cost Measurement

The Cloud Provider Cost estimation by Instance graph represents the key figures of the resource cost for a process instance regarding the entire executed instances. The below graph describes the Cloud Provider Cost by Instance.

Figure 60: Cloud Provider Cost Measurement by Instance

The Cloud Provider total Cost graph represents the resource cost of entire cloud service. The below graph describes the Cloud Provider Total Cost.

Figure 61: Cloud Provider Global Cost

6.5.7 Cloud Provider Utilization:


The Cloud Provider Utilization graph represents the rate of resource utilization through the total simulation time span. The bellow graph describes the Cloud Provider Utilization.

Figure 62: Cloud Provider Utilization

The Cloud Provider Utilization by Instance graph represents the key figures of the resource utilization for a process instance regarding all the executed instances. The bellow graph describes the Cloud Provider Utilization by Instance.

Figure 63: Cloud Provider Utilization by Instance

The Cloud Provider Total Utilization graph represents the resource utilization of entire cloud service. The below graph describes the Cloud Provider Total Utilization.

Figure 64: Cloud Provi der Total Utilization

Network Modeling
(By using Opnet Modeler 14.5) (Chapter-7)

Chapter-7: Network Modeling


7.0 Introduction

In this chapter I have described about the Network Modeling design and Simulation with respect to proposed Cloud Data Control Architecture. To explain workflow of proposed cloud network architectural design the Opnet Modeler 14.5 has been used. Network design pattern, simulation results and also the justification mechanism with respect to the proposed cloud architectural design has been described clearly in this chapter.

7.1

Assumptions of Network Modeling

The bellows are the assumption of proposed cloud network architectural design. The connectivitys between our proposed network architecture devices such as routers, switches and servers is 1Gig. It is assumed that our proposed network having different types of applications traffic. The technology which is used to design the proposed network architecture is ETHRNET technology. The Simulation duration is 30 min for each application scenario.

7.2

Applications Which Involved in the Proposed Architecture


There are some of the applications which are involved in the proposed architecture are as

follows, Delay. E- mail. IP. FTP. HTTP. Data Bases (DB Query etc). Network Utilization.

7.3

Network Simulation Environment

OPNET Modeler:
OPNET Modeler is Software which is used to design the network modeling and also it is useful to find out the performance and behavior of the designed network. This network design software incorporates several types of network suites, devices, protocols and applications. And it consists of a developer environment for network modeling which includes all network technology types.

Figure 65: OPNET Modeler 14.5

7.4

Physical Hierarchical Design


The billow figures are the sample basic physical hierarchical design diagrams of cloud

computing architecture b y using Opnet Modeler 14.5. In this diagram the cloud provider is having three clients from different areas.

Figure 66: A Sample Basic Cloud Computing Architecture

Figure 67: Inner View of Cloud Provider

Figure 68: Inner View of Cloud Presentation/Web Tier

Figure 69: Inner view of Cloud Application Tier

Figure 70: Inner View of Cloud Database Tier

Figure 71: Inner View of Client-1

Figure 72: Inner View of Client-2

Figure 73: Inner View of Client-3

7.5

Network Simulation Results and Analysis with Respect to

Proposed Network
In the above sections prominence was on proposed network modeling. I have given a clear justification about how we design the Network and what its importance. So in this section I am going to emphasis all about the network simulations and its analysis. And one more thing to point out is, in this dissertation simulation work every application was set to 30min time for the network simulation. After some particular times the traffic is standard and to make the simulation work easy the proposed network has been designed in Ethernet and Fast Ethernet Technologies. After completion of all the simulation work Opnet generates the results in graphical manner. In this results and analysis section I have compared the General Cloud Network (Blue Line) and proposed Cloud Network (Red Line) by using time average property. So lets have a look at simulation results and analysis of each and every application.

7.4.0 Network Delay Statistical Results:


The term network delay means the delay it specifies how long a data bit takes to travel across entire network. This is subject to change from network to network, physical media to physical media and also the device to device.

Figure 74: Network Delay of our proposed network (in time average).

Justification: The above statistical results are the comparisons of General Cloud Network Architecture and Proposed Cloud Network Architecture. For each bit of data the general cloud takes 0.00021 (app). On the other hand, for each bit of data the proposed cloud network takes 0.000123 (app). So from the above statistical results our proposed network getting greatest results than the general cloud network. That means the proposed network can control the data easily than general cloud.

7.4.1 DB Query Statistical Results :


The DB Query network application means the request/command line which is from the end user to get or access the response from the DB. The most important statistic of DB Query is Database Response Time. It means The time it takes to access or get the response from the DB.

Response Time:

Figure 75: DB Query Response Time (in time average).

Justification: The above statistical results are the comparisons of General Cloud Network Architecture and Proposed Cloud Network Architecture. The DB Query Response Time of general cloud is 0.0370 (app). On the other hand, The DB Query Response Time of proposed cloud network is 0.0365 (app). So from the above statistical results our proposed network getting greatest results than the general cloud network. That means the proposed network can control the data easily than general cloud architecture.

DB Query Traffic Received:

Figure 76: DB Query Traffic Received (packets / Sec)

Figure 77: DB Query Traffic Received (bytes / Sec)

Justification: The above both statistical results of DB Query Traffic Received (packets / Sec), DB Query Traffic Received (bytes / Sec) are the comparisons of General Cloud Network Architecture and Proposed Cloud Network Architecture. DB Query Traffic Received (packets / Sec) statistical result of general cloud is 09.50(app). On the other hand, The DB Query Traffic Received (packets / Sec) statistical result of proposed cloud network is 10.90(app). Unlike the same DB Query Traffic Received (bytes / Sec) statistical result of general cloud is 160,000(app). On the other hand, The DB Query Traffic Received (bytes / Sec) statistical result of proposed cloud network is 180,000(app). So from the above statistical results our proposed network getting greatest results than the general cloud network. That means the proposed network can control the data traffic easily than general cloud architecture.

DB Query Traffic Sent:

Figure 78: DB Query Traffic Sent (packets / Sec)

Figure 79: DB Query Traffic Sent (bytes / Sec)

Justification: The above both statistical results of DB Query Traffic Sent (packets / Sec), DB Query Traffic Sent (bytes / Sec) are the comparisons of General Cloud Network Architecture and Proposed Cloud Network Architecture. DB Query Traffic Sent (packets / Sec) statistical result of general cloud is 28.20(app). On the other hand, The DB Query Traffic Sent (packets / Sec) statistical result of proposed cloud network is 32.20(app). Unlike the same DB Query Traffic Sent (bytes / Sec) statistical result of general cloud is 160,000(app). On the other hand, The DB Query Traffic Sent (bytes / Sec) statistical result of proposed cloud network is 180,000(app). So from the above statistical results our proposed network getting greatest results than the general cloud network. That means the proposed network can control the data traffic easily than general cloud architecture.

7.4.2 E-mail Server Statistical Results :


The e- mail server is the major application server in the cloud computing architectures, because these are 24/7 busy nodes of cloud network. The major statistical results of e- mail server in the cloud network are Download Response Time and Upload Response Time. The name response time suggests that how much time it takes to respond for upload and download of Email.

Download Response Time:

Figure 80: E-mail Server Download Response Time (in time average).

Justification: The above statistical results are E-mail Server Download Response Time comparisons of General Cloud Network Architecture and Proposed Cloud Network Architecture. The E-mail
Server Download Response Time of general cloud is 0.0049 (app). On the other hand, E-mail Server Download Response Time of proposed cloud network is 0.0047 (app). So from the above statistical

results our proposed network getting greatest results than the general cloud network. That means the proposed network can control the data easily than general cloud architecture.

Upload Response Time:

Figure 81: E-mail Server Upload Response Time (in time average).

Justification: The above statistical results are E-mail Server Upload Response Time comparisons of General Cloud Network Architecture and Proposed Cloud Network Architecture. The E-mail
Server Upload Response Time of general cloud is 0.0034 (app). On the other hand, E-mail Server Upload Response Time of proposed cloud network is 0.0032 (app). So from the above statistical

results our proposed network getting greatest results than the general cloud network. That means the proposed network can control the data easily than general cloud architecture.

E-mail Server Traffic Received:

Figure 82: E-mail Server Traffic Received (packet/sec).

Figure 83: E-mail Server Traffic Received (bytes/sec).

Justification: The above both statistical results of E-mail Server Traffic Received (packets / Sec), E-mail
Server Traffic Received (bytes / Sec) are the comparisons of General Cloud Network

Architecture and Proposed Cloud Network Architecture. Even at some levels (means at the time of network starts) our proposed network generated 4.4 packets/sec 3350 bytes/sec traffic. Then it decreases gradually and reached the normal stage. E-mail Server Traffic Received (packets / Sec) statistical result of general cloud is 0.80(app). On the other hand, The E-mail Server Traffic
Received (packets / Sec) statistical result of proposed cloud network is 01.10(app). Unlike the

same E-mail Server Traffic Received (bytes / Sec) statistical result of general cloud is 650(app). On the other hand, The E-mail Server Traffic Received (bytes / Sec) statistical result of proposed cloud network is 800(app). So from the above statistical results our proposed network getting greatest results than the general cloud network. So I strongly say that the proposed network can control the data traffic easily than general cloud architecture.

E-mail Server Traffic Sent:

Figure 84: E-mail Server Traffic Sent (packet/sec).

Figure 85: E-mail Server Traffic Sent (bytes/sec).

Justification: The above both statistical results of E-mail Server Traffic Sent (packets / Sec), E-mail Server
Traffic Sent (bytes / Sec) are the comparisons of General Cloud Network Architecture and

Proposed Cloud Network Architecture. Even at some levels (means at the time of network starts) our proposed network generated 4.4 packets/sec 3350 bytes/sec traffic. Then it decreases gradually and reached the normal stage. E-mail Server Traffic Sent (packets / Sec) statistical result of general cloud is 0.80(app). On the other hand, The E-mail Server Traffic Sent (packets / Sec) statistical result of proposed cloud network is 01.10(app). Unlike the same E-mail Server Traffic
Sent (bytes / Sec) statistical result of general cloud is 650(app). On the other hand, The E-mail Server Traffic Sent (bytes / Sec) statistical result of proposed cloud network is 800(app). So from

the above statistical results our proposed network getting greatest results than the general cloud network. So I strongly say that the proposed network can control the data traffic easily than general cloud architecture.

7.4.3 HTTP Statistical Results :


HTTP stands for Hyper Text Transfer Protocol. It is an internet protocol and also a generic object oriented protocol. This can be used for a numerous similar schedules/tasks like distributed OO systems, name servers, by extending methods or commands which is already used. The major network statistics of HTTP are Page Response Time, Object Response Time and Traffic. HTTP Page Response Time:

Figure 86: HTTP Page Response Time (in time average).

Justification: The above statistical results are HTTP Page Response Time comparisons of General Cloud Network Architecture and Proposed Cloud Network Architecture. The HTTP Page Response Time of general cloud is 0.0060 (app). On the other hand, HTTP Page Response Time of proposed cloud network is 0.0057 (app). So from the above statistical results our proposed network getting greatest results than the general cloud network. That means the proposed network can control the data easily than general cloud architecture.

HTTP Object Response Time:

Figure 87: HTTP Object Response Time (in time average).

Justification: The above statistical results are HTTP Object Response Time comparisons of General Cloud Network Architecture and Proposed Cloud Network Architecture. The HTTP Object
Response Time of general cloud is 0.0022 (app). On the other hand, HTTP Object Response Time of

proposed cloud network is 0.0022 (app). So from the above statistical results our proposed network and the general cloud network are getting almost similar results. That means there is no point of client dissatisfaction with our proposed network architecture.

HTTP Traffic Received:

Figure 88: HTTP Traffic Received (bytes/sec).

Figure 89: HTTP Traffic Received (packets/sec).

Justification: The above both statistical results of HTTP Traffic Received (packets / Sec), HTTP Traffic
Received (bytes / Sec) are the comparisons of General Cloud Network Architecture and

Proposed Cloud Network Architecture. HTTP Traffic Received (packets / Sec) statistical result of general cloud is 11.75(app). On the other hand, The HTTP Traffic Received (packets / Sec) statistical result of proposed cloud network is 12.75(app). Unlike the same HTTP Traffic Received (bytes / Sec) statistical result of general cloud is 9000(app). On the other hand, The HTTP Traffic
Received (bytes / Sec) statistical result of proposed cloud network is 10,000(app). So from the

above statistical results our proposed network getting the favor results than the general cloud network. That means the proposed network can control the data traffic easily than general cloud architecture. HTTP Traffic Sent:

Figure 90: HTTP Traffic Sent (packets/sec).

Figure 91: HTTP Traffic Sent (bytes/sec).

Justification: The above both statistical results of HTTP Traffic Sent (packets / Sec), HTTP Traffic Sent (bytes / Sec) are the comparisons of General Cloud Network Architecture and Proposed Cloud Network Architecture. HTTP Traffic Sent (packets / Sec) statistical result of general cloud is 11.75(app). On the other hand, The HTTP Traffic Sent (packets / Sec) statistical result of proposed cloud network is 12.75(app). Unlike the same HTTP Traffic Sent (bytes / Sec) statistical result of general cloud is 9000(app). On the other hand, The HTTP Traffic Sent (bytes / Sec) statistical result of proposed cloud network is 10,000(app). So from the above statistical results our proposed network getting the favor results than the general cloud network. That means the proposed network can control the data traffic easily than general cloud architecture.

7.4.4 FTP Statistical Results:


FTP stands for File Transfer Protocol. It is a technique/method to transfer files across the World Wide Web or Internet. This can be commonly used by the web publishers and the campus networks. The major network statistics of FTP are Download Response Time, Upload Response Time and Traffic. FTP Download Response Time:

Figure 92: FTP Download Response Time (in time average).

Justification: The above statistical results are FTP Download Response Time comparisons of General Cloud Network Architecture and Proposed Cloud Network Architecture. The FTP Download
Response Time of general cloud is 0.008 (app). On the other hand, FTP Download Response Time of

proposed cloud network is 0.007 (app). So from the above statistical results our proposed network getting finest results than the general cloud network. That means the proposed network can control the data easily than general cloud architecture.

FTP Upload Response Time:

Figure 93: FTP Upload Response Time (in time average).

Justification: The above statistical results are FTP Upload Response Time comparisons of General Cloud Network Architecture and Proposed Cloud Network Architecture. The FTP Upload
Response Time of general cloud is 0.0075 (app). On the other hand, FTP Upload Response Time of

proposed cloud network is 0.0075 (app). So from the above statistical results our proposed network and the general cloud network are getting almost similar results. So that means there is no point of client dissatisfaction with proposed network architecture.

FTP Traffic Received:

Figure 94: FTP Traffic Received (packets/sec).

Figure 95: FTP Traffic Received (bytes/sec).

Justification: The above both statistical results of FTP Traffic Received (packets / Sec), FTP Traffic
Received (bytes / Sec) are the comparisons of General Cloud Network Architecture and Proposed

Cloud Network Architecture. Even at some levels (means at the time of network starts) our proposed network generated 1.07 packets/sec 3000 bytes/sec traffic. Then it decreases gradually and reaches the normal stage. FTP Traffic Received (packets / Sec) statistical result of general cloud is 0.15(app). On the other hand, The FTP Traffic Received (packets / Sec) statistical result of proposed cloud network is 0.15(app). Unlike the same FTP Traffic Received (bytes / Sec) statistical result of general cloud is 650(app). On the other hand, The FTP Traffic Received (bytes / Sec) statistical result of proposed cloud network is 650(app). So from the above statistical results our proposed network and the general cloud network are getting the similar results. So there is no point of client dissatisfaction with our proposed cloud network architecture. FTP Traffic Sent:

Figure 96: FTP Traffic Sent (packets/sec).

Figure 97: FTP Traffic Sent (bytes/sec).

Justification: The above both statistical results of FTP Traffic Sent (packets / Sec), FTP Traffic Sent (bytes / Sec) are the comparisons of General Cloud Network Architecture and Proposed Cloud Network Architecture. Even at some levels (means at the time of network starts) our proposed network generated 1.07 packets/sec 3000 bytes/sec traffic. Then it decreases gradually and reaches the normal stage. FTP Traffic Sent (packets / Sec) statistical result of general cloud is 0.15(app). On the other hand, The FTP Traffic Sent (packets / Sec) statistical result of proposed cloud network is 0.15(app). Unlike the same FTP Traffic Sent (bytes / Sec) statistical result of general cloud is 625(app). On the other hand, The FTP Traffic Sent (bytes / Sec) statistical result of proposed cloud network is 625(app). So from the above statistical results our proposed network and the general cloud network are getting the similar results. So there is no point of client dissatisfaction with our proposed cloud network architecture.

7.4.5 IP Statistical Results:


IP stands for Internet Protocol. This is the most important network protocol which is used on the internet. IP supports the unique addressing of devices on a network. The major network statistics of IP are Network Convergence Activity, Traffic dropped (packets/sec) and Number of Hops. Network Convergence Activity: Network Convergence is also called as Media Convergence. It is the well-organized coexistence of video, data communication and telephone within a single network. This activity is very useful while there is no possibility of flexibility and convenience.

Figure 98: IP Network Convergence Activity (in time average).

Justification: The above statistical results are IP Network Convergence Activity comparisons of General Cloud Network Architecture and Proposed Cloud Network Architecture. In most of the cases The General cloud architectures doesnt support IP Network Convergence Activities. On the other hand, IP Network Convergence Activity of proposed cloud network is 01.000 (app). So from the above statistical results our proposed network can deal all IP Network Convergence Activities. IP Traffic Loss:

Figure 99: IP Traffic dropped (in time average).

Justification: The above statistical results are IP Traffic dropped comparisons of General Cloud Network Architecture and Proposed Cloud Network Architecture. The general cloud architecture and the proposed architectures dont drop any packets. So from the above statistical results our proposed network and the general cloud network are getting the similar results. So there is no point of client dissatisfaction with our proposed cloud network architecture.

7.4.6 Network Utilization: The statistics network utilization describes the resources consumption ratio. That mean how resources are consumed/utilized in the proposed cloud network architecture. Network Utilization-In (Point-to-Point )

Figure 100: Network Utilization-In (Point-to-Point)

Justification: The above statics are the Network Point-to-Point utilization from Client to Cloud. From the starting of the proposed network the utilization rate increases gradually and reaches particular level. So the above statics our proposed network consumes the resources in a sufficient manner.

Network Utilization-Out (Point-to-Point ):

Figure 101: Network Utilization-out (Point-to-Point)

Justification: The above statics are the Network Point-to-Point utilization from Cloud to Client. From the starting of the proposed network the utilization rate increases gradually and reaches particular level. So the above statics our proposed network consumes the resources in a sufficient manner.

Conclusion
(Chapter-8)

Chapter-8: Conclusion
8.0 Evaluation & Future Work:
After a wide spread study on Cloud Computing Architecture and Cloud Security Issues there are some limitations with which the cloud providers are feuding up. Based on the consideration of these limitations this project has been designed. The main intend of this project is Data controlling in the Cloud. By controlling the data in cloud computing architectures the cloud providers can provide better services to their clients/customers than the general cloud architectures. The cloud providers providing the services to the client with a regular internet, network technology (LAN or WAN or MAN) and its security based data flow. But according to our proposed cloud network architecture the data flow of cloud will be divided into three parts such as Data in Use Data at Motion and Data at Rest. And also this technique will be implemented by using Clustering Mechanism to prevent the attacks from the legitimate users. To simulate the proposed network there are two pieces of software has been used in this project such as Bonita Open Solutions 5.5 for Business Process Modeling ,Opnet Modeler v14.5 for Network Modeling. With the business process modeling software (i.e., Bonita Open Solutions 5.5) we can get the simulation results with respect to how the internal instances flow is running and how much is the execution times, waiting times and the cumulated times for each instance and also with this business process modeling we can measure the utilizations and cost estimations as well. By the network modeling software (i.e., Opnet Modeler v14.5) we can get the simulation results with respect to network delays, utilizations, and page and object response times upload and download times and device to device work flows. With this proposed cloud network architecture the cloud providers are able to provide the data services better and secure than the normal flow. But there is a limitation with in this proposed cloud architecture, which is while the data is on flow it must use the clustering mechanism to prevent the attacks from the legitimate users/attackers. Now the problem is, for further data transmissions the client has to wait a few more fractions of seconds extra than general cloud architecture for his/her first data request. So finally I am sure that our proposed network can control the data efficiently than regular cloud architectures.

Appendix - A

Cloud Data Controlling Process in Bonita Open Solution


Version 5.5

Quick Start User Guide

Welcome to BOS-5.5!
Use this Quick Start User Guide to get started with Bonita Open Solution and become familiar with its graphic tools for process design.

Part-1: Overview of BOS-5.5

1.1 Download, install, and launch Bonita Open Solution 5.5


Bonita Open Solution 5.5 is now available from the Download BPM software and documentation page at www.bonitasoft.com. (http://www.bonitasoft.com/products/BPM_downloads)

When the zipped file has been downloaded, extract all files to a target folder. To launch Bonita Open Solution and begin designing a process: Open the target folder. Launch the Bonita Studio application file for your operating system.

1.2 General Description

Bonita Studio is the graphic process design interface of Bonita Open Solution. The Welcome screen, shown below, is what you see when you launch Bonita Open Solution.

Figure 1: Welcome to Bonita Studio in Bonita Open Solution

1.3 Whiteboard in Bonita Studio


The screen shown below shows where you draw your processes.

Figure 2: A Cloud Design Process on the Bonita Studio Whiteboard

Part-2: Starting up of Bonita Studio


After installation of BOS-5.5, if you click on New tab to enter Bonita Studio and you could see the Whiteboard and several bars, panels beside it; these provide tools to design a Process. Lets see some more about these tools before start our cloud security process design.

2.1 Menu Bar


It allows the designer to choose major actions from drop-down menus.

Figure 3: Menu bar in BOS-5.5

Each tab in the menu bar contains several options which we use generally in every application. The bellow table shows all options which are available in menu bar.

Process Edit Run Vie w

Open, Save, Import and Export, Print, and more Undo, Redo, Copy, Paste, and more Run, Deploy, Preview Forms, Open User Experience and more Reset the Whiteboard and panels if you have minimized any of them and change the size of the Task bar (Cool bar)

Extensions

Browse and Add or Remove processes, Resources, and more from the Community

Connectors

Create, Edit, Test, Import Connectors, Define Actor Selectors, Define Filters, and more

Simulation

Manage, Import, Export Simulation Resources and Run simulations

Help

Return to the welcome page, Jump to the Help page, Find Bonita Studio and Bonita Execution Engine logs

2.2 Task bar


The Task Bar is used to start a ne w Process / to Open an existing process / to Save, Print, Import, Export, Copy, Paste, Run a Process / to Debug a process and change Preferences. You can also open the User Experience from here and Preview Forms as you design them. Jump to the central Help page or return to the Welcome page from here. We can make to disappear or resize the Task bar through the View menu in the Menu bar.

Figure 3: Bonita Open Solution Task bar

2.3 Whiteboard
The Whiteboard is a GUI (Graphical User Interface) tool to draw a process. It allows the user / designer to draw, inside a single Process Diagram, one or more Pools, and multiple Lanes within each Pool. We can Hide and resize the tool bars.

Figure 4: BOS-5.5 is now re ady to design our cloud security Process

2.4 Pools & Lanes


Pool: It is equivalent to a stand-alone Process and contains all the elements and resources needed to deploy a complete Process. It can contain one or more Lanes which might represent different organizations participating in the process. Lane: These are never standalone; they can exist only within a Pool. They are useful to organize a Process visually, and can be specifically associated with a group of Actors.

When we Save / Save As / Duplicate a Process Diagram, all Processes and all resources are saved together. When you export a Diagram, each Pool (Process) in the diagram is saved as an individual *.bar file in the directory or folder you choose.

Figure 5: Pools and Lanes in our cloud security Process design

2.5 Text Annotation


These are useful to describe something / to describe tasks in our process design. To enter the text in the text annotation we have to go for general customized tab in the bellow of whiteboard.

Figure 6: Text Annotation customization

2.6 Task Types You can define a Task to be performed by a person (human) or by the underlying Bonita Execution Engine (automatic). o Human Tasks (user tasks) require intervention by an Actor. o Call Activity: an element that represents another process. The sub process runs within the sequence of its parent process, but is defined in a separate pool. When the Process reaches the Call Activity task, it automatically runs the sub process and returns to the parent sequence. See How to Call a Sub Process. o Service Tasks are processed entirely by the Bonita Execution Engine. These were previously known as Automatic tasks. o Send Task: A Send Task sends a Message when the Task is reached in the Process. See Create a throw message. o Script Task: A Script Task is a Service Task with a script that executes when the Task is reached in the Process. Define the script to be executed (and when it is to be executed) by implementing a Connector. See How to Configure Connectors. o Abstract Task: an undefined task. Abstract tasks must be changed to one of the previous task types to execute a process.

o Receive Task: A Receive Task waits to receive a Message when the Task is
reached in the Process. See Create a Catch message.

2.7 Define General Details for a Task


For each Task, the Details panel offers the following options in the General tab:

Figure 7: Detail Panel for a Task: General

In General, you can enter a fixed Name and Description of the Task.

Here you can change the Task type, and select the Priority for a Human Task: Normal, High, or Urgent. Use Advanced tab is used to Create the capability for multiple instances, Loop and Change the Step from synchronous to asynchronous.

Use UserXP to apply a dynamic title, description and/or summary for the Step as it will appear in Bonita User Experience or an external Web application. Here you can also specify an estimated execution time for this Step this will be used in User XP to determine when a Step is overdue, or at risk of being overdue. Use Data to define variables. See How to define Data variables. Use Actors to assign Users to a Task (for Human Tasks only). See How to assign Actors to a Task.

Use Connectors to connect Tasks in the Process to external information systems. (See How to Configure a Connector.)

2.8 Application Tab


The Application tab allows you to define Forms at the Pool and Step level. You can also define what order the Forms appear in. Entry forms are user- interactive; View and Overview forms are read-only. At the Pool level, the Application tab also provides functions to change external web resources and the look-and- feel for the user interfaces (forms, welcome page, log-in, page, confirmation messages, and more). The Transient Data tab located here also allows you to define variables that are temporarily useful within any form. The Form Builde r at this level allows us to design an entry page. We discuss the usage of Form builder in the later chapters. Form Builder is used to create Forms for each Task, for the Process initialization, and for overviews during the Process run. You can find the Form Builder in the Application tab at the Pool and Step levels. It will appear when you select Add (Entry Page flow, View Page flow, or Overview Page flow) and complete the Create a new Form wizard. Use Entry Page flow to create pages to display to the End User they allow data entry (interactive). Use Vie w Page flow to create pages that are visible when you consult Cases in the List of Cases (history) in User Experience.

Part-3: Starting up of Cloud Data Controlling (Cloud Security) Process Idea 3.1 Designing of Cloud security Idea.
Launch Bonita Studio Click on New Process on the Welcome screen, under the Design menu.

Figure 8: New Process

After you click on New Process it opens a Process Diagram called MyProcessDiagram (1.0), which contains a Pool called My Process in Whiteboard. At any time if you want to rename / customize the design, use Edit Button in General tab bellow the white board / beside the overview window.

Figure 9: Customize the Process We can customize every task of our process by this general group tab. After we go to the design part the Start1 and Step1 are already set up by default on the Whiteboard.

Figure 10: A default My Process Design

3.2 Use of Context palette


If you select an element / task on the Whiteboard, you can see a highlighted Context Palette. Use this to avoid the drag & drops of Tasks and Transitions from Design Palettes at the left to the Whiteboard as your requirement. It can be useful to Design faster!

Figure 11: Context Palette

3.3 Design Tasks and Transitions according to our cloud process requirement 3.3.1 Design Client area
Click on the Default Pool called My Process which containing Start1 and Step1. From the Design Palette on the left, Drag and drop a new End Message task, and connect next to Step 1 on the Whiteboard.

Figure 12: an End Message event

Customize the Pool, Step1 and End Message tasks by using General tab according to our cloud security requirement an also drag & drop the text annotation and connect it to customized step1 task.

Figure 13: Client Pool of our Cloud Process Design

In this client area we need to design an Entry Page Flow to send the request to the Cloud. To design this entry page flow we need to go for Entry page flow in Application tab which bellows the whiteboard. First select the data request task then go for the Entry page Flow option.

Figure 14: Entry Page Flow

At this level (Client pool), the Application tab allows us Entry Page flow option to design entry page: Click on the Add button (See above figure) It opens a Create a new Form window
Define all requirements i.e., Name

Description etc...
After Click on finish it will be redirected to

another tab called Form Builde r.

Figure 15: Create a new Form window

Here we have to design our Entry page Flow for the client pool.

Figure 16: Form Builder in BOS-5.5

Add an action to the Send Request button by using Details Palette->action-> Add action option.

Figure 17: Form Builders Add action in Details tab

Select ${field_Text1} in Expressions drop down list. Check the save to option If you want save the requirement. Then it enables the other dropdown list box. Here you have to finish the create data wizard. After completion of form builder how it is appear in the form builders grid, same like that it appears in the user experience. After finish clients requests aspect, add Message to the End Message Task by using Details Palette -> General -> Messages option.

Figure 18: End Message

Click on Add And follow the Add Message wizard In this wizard we need to add data to store data requests which are sending by the Client to the Cloud.

Figure 19: Add Message wizard

Click on Add / Or (you can add the existing Data base) And follow the Add data wizard

Figure 20: New Add Data wizard

3.3.2 Design Cloud Provider


Same design like Client area in the above we have to design the Clo ud Provider aspect. Have a look at bellow steps, Drag & Drop the pool from the palette and name it as Cloud Provider Here we need Drag & Drop the three lanes (because he have to connect three design aspects) and name those as, o Cloud Management Team / Security Pool o Data Centre / Security Pool o Intrusion Rejection Process Design all tasks as show in the bellow figure

Figure 21: Cloud Provider design

For the Data Check-in task in the Cloud Management Team / Security Pool, we have to assign Connectors which is in General tab.

Figure 22: Assign connectors for Data Check-in Task

Click on Add And follow the connectors wizard (For Our example we have to select File check- in option).

Figure 23: Choosing Connector (Connectors Wizard)

2.9 For the Data Mode for Transmission task in the Cloud Management Team / Security Pool, we have to assign Mappings which are in General tab, because we make it as a Call activity Task. (for more information please refer 2.7 Define General Details for a Task) This will be useful to assign Source and Sub process data to Valid Check-in data.

Making a Task as Call Activity Select the task to make it as Call Activity Go to Gene ral tab And choose the Task type as Call Activity

Figure 24: Making a task as Call Activity

Mapping the Call Activity Task Select the task which made as Call Activity Go to Gene ral tabs Mapping Option And fill the Source data and Sub process data options

Figure 25: Mapping a Call Activity task

In the next section i.e., Data Centre / Security Pool, I am going to implement My Idea to control the data at cloud data centers. Controlling the data in cloud means this is one of the security aspects of cloud architecture.

My Cloud Idea

According to my idea we have to divide the data (which is transmits from Client to Cloud and vice versa) in three possible ways. Such as, Data in Use Data at the Rest Data in Motion

In this model I have chosen an XOR Gate Before and after these three services, because it doesnt allow any two requested data at the same time. The Truth table for the XOR gate is as follows.

A 0 0 0 0 1 1 1 1

B 0 0 1 1 0 0 1 1

C 0 1 0 1 0 1 0 1

XOR 0 1 1 0 1 0 0 0

Table 1: XOR Truth Table

Figure 26: Data Division and XOR Gates

Advantages of Data Division Data Centers can manage the data load easily We can provide the security more highly and reliably The performance of cloud network cold improve highly We can detect the exceptions / intrusions easily.

And many more After finish this section we have to design an important task called o Data Security Area - Here we can apply the cryptographic techniques to make the data secure and to avoid the attacks o Data Centre Updation - After All the completion of client and cloud processes finish the final task will be applied i.e., the updating of data centers...

Figure 27: Data Security area and Data Centre Updation

Now we are going to final section of Cloud Provider pool i.e., Intrusion Rejection Process. Here we have two tasks such as, o Raise Alarm (Service alarm task) - If any invalid data/ intrusion/virus is detected then it raise the alarm. o Compose Rejection E-mail/Msg to Client (Send Message task) after alarm intimation composes a rejection e-mail / Message according to the error and it will be sent to client and also store in cloud security managements data base. For this we have to compose the message in Details palettes>General-> Messages tab like in client sections end message task.

Figure 28: Raise alarm & Compose Rejection E-mail/Msg to Client Tasks

Run / Debug the Entire Process

Debug - This process Disconnect the Connectors to test run process. Run - This process doesnt disconnect the Connectors to test run process.

Figure 29: Run & Debug Icons in Task Bar To run the process just click on Run icon in the task Bar

Figure 30: Run & Debug Process

When this process completed, a form appears in the Bonita Open Solution web application, and you are automatically logged in as the User named admin. You enter data in its fields and click Data Request to start the Process, or immediately click on Bonita User Experience to open the inbox.

Figure 31: Open the Bonita User Experience inbox in the default web application

The Process will show up in the admin inbox. As you run this first Case, you can enter data in the application fields Step by Step. This will complete the first Case of the Process.

Figure 32: After Click on Bonita User Experience inbox in the default web application

My Section for BOS 5.5

These are the main tools used and over view about BOS-5.5. I have prepared this document as part of my masters dissertation work. Note: This document is recommended for those who know the basics about cloud computing, the scope of this topic is limited, as I have only explained my cloud computing idea as an example throughout this document. My Special Thanks to Dr. Muthu Ramachandran Sir who helped me a lot to prepare this Quick Start User Guide.

Thank You, VAMSI KRISHNA.MANNAVA Leeds Metropolitan University Student Id: 77090470

Bibliography
(Chapter-9)

Chapter-9: Bibliography
Alan Williamson [2009]. Measuring Cloud Performance, Cloud Computing Journal [Internet]. Available From: < http://www2.sys-con.com/cloud/pdf/CCJournal_2-3_SPREAD.pdf> [Accessed 17th August, 2011]. Amit Nath [2009]. Cloud Computings toughest obstacle, Article of Indian Express Magazine [Internet]. Available From: < http://www.indianexpress.com/news/cloud-computingstoughest-obstacle/765069/0> [Accessed 27th August, 2011].

Bonita Open Solutions-5.5 [Internet]. Available From: <http://www.bonitasoft.com/> [Accessed


2nd June, 2011].

Chow R, et. al [2009]. Controlling Data in the Cloud : Outsourcing Computation without Outsourcing Control Journal of CCSW09, November, [Internet]. Available From: <http://www.parc.com/content/attachments/ControllingDataInTheCloud-CCSW-09.pdf > [Accessed 5th February, 2011]. Cloud News Desk [2009]. The Impact of Cloud Computing on Enterprise Architecture, Cloud Computing Journal [Internet]. Available From: < http://cloudcomputing.syscon.com/node/900838> [Accessed 20th August, 2011].

Dustin Amrhein [2011]. Exploring Cloud deployment Models in IBM Workload Deployer, Cloud Computing Journals [Internet]. Available From: <http://cloudcomputing.syscon.com/node/1827140> [Accessed 4th August, 2011].

David Hobson [2009]. Cloud Security: Into the Cloud We Go, Cloud Computing Journal [Internet]. Available From: < http://cloudcomputing.sys-con.com/node/1006231> [Accessed 19th August, 2011]. Don Macvittie [2011]. Whither Cloud Gateways, A Journal of Cloud Backup and Recovery [Internet]. Available From: <https://cloudbackup.ulitzer.com/node/1950893> [Accessed 6st September, 2011].

Haley Beard [2009] .Cloud Computing Best Practices for Managing and Measuring Processes for on demand computing, applications and data centers in the cloud with SLAs. Emereo Pty Limited. Imad Mouline [2009]. Why Assumptions About Cloud Performance Can Be Dangerous, Cloud Computing Journal [Internet]. Available From: <http://cloudcomputing.syscon.com/node/957492> [Accessed 26th August, 2011].

Ingthorsson O, [2010]. Cloud Computing-Data protection and Compliance Cloud Computing Topics [Internet]. Available from: <http://cloudcomputingtopics.com/2010/03/cloudcomputing-data-privacy-and-compliance/> [Accessed 15th August, 2011].

Jeff Fisher [2009]. Benefit Now with Cloud-Hosted Desktops, Cloud Computing Journal [Internet]. Available From: < http://cloudcomputing.sys-con.com/node/892352> [Accessed 22th August, 2011].
Jhon W. Rittinghouse, James F. Ransome [2009]. Cloud Computing : Implementation, Management, and Security. CRC Press, Taylor and Francis Group.

Jeremy Geelan [2010]. The Top 150 Players in Cloud Computing, A Journal of Cloud Backup and Recovery [Internet]. Available From: <https://cloudbackup.ulitzer.com/node/770174> [Accessed 1 st September, 2011]. Kenneth Oestreich [2009]. Building a Real-World IaaS Cloud Foundation, Cloud Computing Journal [Internet]. Available From: < http://cloudcomputing.syscon.com/node/976449> [Accessed 23th August, 2011].

Kevin Harting [2009]. What is Cloud Computing?, Cloud Computing Journal [Internet]. Available From: < http://cloudcomputing.sys-con.com/node/579826> [Accessed 26th August, 2011].
Lizhe W, et. al [2011]. Cloud Computing : Methodology, System, and Applications. CRC Press, Taylor and Francis Group.

Lori Macvittle [2010]. Data Inventory Control, a journal of Virtualization [Internet]. Available From: < http://virtualization.sys-con.com/node/1438127> [Accessed 11th June, 2011]. Nicos Vekiarides [2011]. How to Simplify Off-site Backup for Virtual Environments, A Journal of Cloud Backup and Recovery [Internet]. Available From: <https://cloudbackup.ulitzer.com/node/1982318> [Accessed 15st September, 2011]. Opnet [Internet]. Available From: < http://www.opnet.com/solutions/index.html> [Accessed 1st March, 2011]. Opencloudmanifesto [2009]. Cloud Computing Use cases, White Paper [Internet]. Available From: < http://opencloudmanifesto.org/Cloud_Computing_Use_Cases_Whitepaper2_0.pdf> [Accessed 29th July, 2011].

Peter Mell, Tim Grance [2009]. Effectively and Securely Using the Cloud Computing Paradigm, NIST Information Technology Laboratory [Internet]. Available From: <http://csrc.nist.gov/groups/SNS/cloud-computing/cloud-computing-v26.ppt > [Accessed 14th June, 2011]. Raj Kumar B, et. al [2009]. Future Generation Computer Systems, Cloud Computing and emerging IT platforms: Vision, hype, and reality for delivering computing as the 5 th utility Journal [Internet]. Available From: <http://www.sciencedirect.com/science/journal/0167739X> [Accessed 13th August, 2011]. Rajkumar B, et.al [2009] .Cloud Computing: Principals and Paradigms. Wiley Press, New York, USA. SrinivasaRao V, et. al [2009]. Cloud Computing: An Over View, Journal of Theoretical and Applied Information Technology [Internet]. Available From: <http://www.jatit.org/volumes/research-papers/Vol9No1/10Vol9No1.pdf> [Accessed 14th August, 2011]. Scott Young [2009]. Cloud Computing and The Enterprise, Cloud Computing Journal [Internet]. Available From: < http://cloudcomputing.sys-con.com/node/969655> [Accessed 19th August, 2011].

Securosis [2009]. Cloud Data Security: Use (Rough Cut) [Internet Blog]. Available From: <
http://securosis.com/blog/cloud-data-security-use-rough-cut/> [Accessed 29th August, 2011].

Salvatore Genovese [2009]. Cloud Security Alliance and IEEE on Cloud Computing Security, Web Security Journal [Internet]. Available From: < http://security.syscon.com/node/1290824> [Accessed 29th June, 2011].

S Raju [2011]. 6 Customer Rights For Cloud Data Security, Tools Journal [Internet]. Available From: < http://www.toolsjournal.com/cloud-articles/item/260-6-customer-rights-forcloud-data-security> [Accessed 6th June, 2011].

Steve Lesem [2010]. Enterprise IT: should you build your own Private Cloud? Cloud Storage Strategy Journal [Internet]. Available From: <http://cloudstoragestrategy.com/cloudtaxonomy/> [Accessed 9th June, 2011].

Saurabh Singh [2009]. Security Issues in Cloud Computing, pdfqueen [Internet]. Available From: < http://www.pdfqueen.com/security-issues-in-cloud-computing.ppt> [Accessed 1th June, 2011]. Treacy B, et.al [2009]. Cloud Computing- data protection concerns unwrapped Privacy & Data Protection [Internet]. Available from: <http://cloudcomputingtopics.com/2010/03/cloudcomputing-data-privacy-and-compliance/> [Accessed 16th June, 2011].

Tim Negris [2010]. Cloud Control : Customers versus Vendors, A Journal of Cloud Computing [Internet]. Available From: < https://cloudcomputing.sys-con.com/node/1611676> [Accessed 17th June, 2011]. Won K, et. al [2009]. Cloud Computing: Today and Tomorrow, Journal of Object Technology [Internet]. Available From: <http://www.jot.fm/issues/issue_2009_01/column4.pdf > [Accessed 11th August, 2011].

You might also like