Complying with Data Handling Requirements in Cloud

ABSTRACT
In past years, cloud storage systems saw an enormous rise in usage. However, despite their popularity
and importance as underlying infrastructure for more complex cloud services, today’s cloud storage systems
do not account for compliance with regulatory, organizational, or contractual data handling requirements by
design. Since legislation increasingly responds to rising data protection and privacy concerns, complying with
data handling requirements becomes a crucial property for cloud storage systems. We present PRADA, a
practical approach to account for compliance with data handling requirements in key-value based cloud
storage systems. To achieve this goal, PRADA introduces a transparent data handling layer, which empowers
clients to request specific data handling requirements and enables operators of cloud storage systems to
comply with them. We implement PRADA on top of the distributed database Cassandra and show in our
evaluation that complying with data handling requirements in cloud storage systems is practical in real-world
cloud deployments as used for micro blogging, data sharing in the Internet of Things, and distributed email
storage.
 CHAPTER 1
INTRODUCTION
 

1.1 GENERAL:

Now a day’s many web services outsource the storage of data to cloud storage systems. While this offers multiple benefits, clients
and lawmakers frequently insist that storage providers comply with different data handling requirements (DHRs), ranging from restricted
storage locations or durations to properties of the storage medium such as full disk encryption. However, cloud storage systems do not
support compliance with DHRs today. Instead, the selection of storage nodes is primarily optimized towards reliability, availability, and
performance, and thus mostly ignores the demand for DHRs. Even worse, DHRs are becoming increasingly diverse, detailed, and difficult
to check and enforce, while cloud storage systems are becoming more versatile, spanning different continents or infrastructures, and even
second-level providers. Hence, clients cannot ensure compliance with DHRs when their data is outsourced to cloud storage systems.

This apparent lack of control is not merely an academic problem. Since customers have no influence on the treatment of their data
in today’s cloud storage systems, a large set of customers cannot benefit from the advantages offered by the cloud. The Intel IT Center
surveys [9] among 800 IT professionals, that 78% of organizations have to comply with regulatory mandates. Again, 78% of organizations
are concerned that cloud offers are unable to meet their requirements. In consequence, 57% of organizations actually refrain from
outsourcing regulated data to the cloud. The lack of control over the treatment of data in cloud storage hence scares away many clients.
This especially holds for the healthcare, financial, and government sectors.
 Supporting DHRs enables these clients to dictate adequate treatment of their data and thus allows cloud storage
operators to enter new markets. Additionally, it empowers operators to efficiently handle differences in regulations (e.g., data
protection). Although the demand for DHRs is widely acknowledged, practical support is still severely limited. Related work
primarily focuses on DHRs while processing data, limits itself to location requirements, or treats the storage system as a black
box and tries to coarsely enforce DHRs from the outside. Practical solutions for supporting arbitrary DHRs when storing data
in cloud storage systems are still missing – a situation that is disadvantageous to clients and operators of cloud storage
systems.

Our contributions. In this paper, we present PRADA, a general key-value based cloud storage system that offers rich
and practical support for DHRs to overcome current compliance limitations. Our core idea is to add one layer of indirection,
which flexibly and efficiently routes data to storage nodes according to the imposed DHRs. We demonstrate this approach
along classical key-value stores, while our approach also generalizes to more advanced storage systems. Specifically, we make
the following contributions:

 We comprehensively analyze DHRs and the challenges they impose on cloud storage systems. Our analysis shows that a
wide range of DHRs exist, which clients and operators of cloud storage systems have to address.

 We present PRADA, our approach for supporting DHRs in cloud storage systems. PRADA adds an indirection layer on top
of the cloud storage system to store data tagged with DHRs only on nodes that fulfill these requirements. Our design of
PRADA is incremental, i.e., it does not impair data without DHRs. PRADA supports all DHRs that can be expressed as
properties of storage nodes as well as any combination thereof. As we show, this covers a wide range of actual use cases.

 We prove the feasibility of PRADA by implementing it for the distributed database Cassandra (we make our
implementation available) and by quantifying the costs of supporting DHRs in cloud storage systems. Additionally, we
show PRADA’s applicability in a cloud deployment along three real-world use cases: a Twitter clone storing two million
authentic tweets, a distributed email store handling half a million emails, and an IoT platform persisting 1.8 million IoT
1.5 EXISTING SYSTEM
 
Existing work primarily focuses on DHRs while processing data, limits itself to location
requirements or treats the storage system as a black box and tries to coarsely enforce DHRs from the
outside.
Practical solutions for supporting arbitrary DHRs when storing data in cloud storage systems are
still missing – a situation that is disadvantageous to clients and operators of cloud storage systems.

1.5.1 DISADVANTAGE OF EXISTING SYSTEM

Provide less security, feasibility, supporting.

Practical solutions for supporting arbitrary DHRs when storing data in cloud storage systems are still missing – a
situation that is disadvantageous to clients and operators of cloud storage systems.
 1.5.2 LITERATURE SURVEY

TITLE : Distributed SECONDO: A Highly Available and Scalable System for Spatial Data Processing
AUTHOR : J. K. Nidzwetzki and R. H. G¨ uting
YEAR : 2015
 
DESCRIPTION
 
Cassandra is a highly available and scalable data store but it provides only limited capabilities for data analyses.
However, database management systems (DBMS) provide a lot of functions to analyze data but most of them scale
poorly. In this paper, a novel method is proposed to couple Cassandra with a DBMS. The result is a highly available and
scalable system that provides all the functions from the DBMS in a distributed manner. Cassandra is used as a data store
and the DBMS Secondo is used as a query processing engine. Secondo is an extensible DBMS, it provides various data
models, e.g. models for spatial data and moving objects data. With Distributed Secondo functions like spatial joins can be
performed distributed and parallelized on many computers.
TITLE : Monitoring Personal Data Transfers in the Cloud
AUTHOR : A. De Oliveira et al.
YEAR : 2013
 
DESCRIPTION

Cloud computing brings a number of compliance risks to organisations because physical perimeters are not clearly
delimited. Many regulations relate to the location of the data processing (and storage), including the EU Data
protection directive. A major problem for cloud service consumers, acting as data controllers, is how to demonstrate
compliance to data transfer constraints. We address the lack of tools to support accountable data localization and
transfer across cloud software, platform and infrastructure services, usually run by data processors. In this paper we
design a framework for automating the collection of evidence that obligations with respect to personal data handling
are being carried out in what concerns personal data transfers. We experiment our approach in the Open Stack open
source IaaS implementation, showing how auditors can verify whether data transfers were compliant.
1.6 PROPOSED SYSTEM

In this paper, we present PRADA, a general key-value based cloud storage system that offers rich and practical support for DHRs to
overcome current compliance limitations.
 Our core idea is to add one layer of indirection, which flexibly and efficiently routes data to storage nodes according to the imposed
DHRs.
We demonstrate this approach along classical key-value stores, while our approach also generalizes to more advanced storage systems.

1.6.1 ADVANTAGES OF PROPOSED SYSTEM

We comprehensively analyze DHRs and the challenges they impose on cloud storage systems.
Our design of PRADA is incremental, i.e., it does not impair data without DHRs.
We prove the feasibility of PRADA by implementing it for the distributed database
 2.2.2 MODULES EXPLANATION AND DIAGRAM

 User Interface Design

To connect with server user must give their username and password then only they can able to connect the server.
If the user already exits directly can login into the server else user must register their details such as username,
password, Email id, City and Country into the server. Database will create the account for the entire user to maintain
upload and download rate. Name will be set as user id. Logging in is usually used to enter a specific page. It will
search the query and display the query.
 User Page

User Login Server

Page

Error
Message

Database
Admin
We comprehensively analyze DHRs and the challenges they impose on cloud storage systems. Our analysis shows
that a wide range of DHRs exist, which clients and operators of cloud storage systems have to address.
2) We present PRADA, our approach for supporting DHRs in cloud storage systems. PRADA adds an indirection
layer on top of the cloud storage system to store data tagged with DHRs only on nodes that fulfill these
Authorized licensed use limited to: Auckland University of Technology.
Admin is the second module in our project, where crucial functional requirements of the project will be
carried out. The roles and responsibilities of the admin are it verify all user request details, and display al users.
 Admin

Login Page

Admin Home Page

User request details Accept user User Files Feed Back

requests

Database
Operator
This is the third module in our project where Operator plays the main part of the project role. Enter operator
name and password then login to the application. First verified in database then display home page. Operator
having some options Files requests, read files, update request and delete request all deleted files. The support of
DHRs presents clear business incentives to cloud storage operators as it opens new markets and eases compliance
with regulation. Business incentives are given by the unique selling point that DHRs present to the untapped
market of clients unable to outsource their data to cloud storage systems nowadays due to unfulfillable DHRs.
Indeed, cloud providers already adapted to some carefully selected requirements.
 Operator

Login Page

Operator Home Page

Files request details Read Files Update requests Delete request

and files

Database
User

This is the fifth module in our project where user process. User has to register and login with valid username and
password. After login successful he can do some operations such as user details. User having some options create
new files, read file, update file and delete file also. User verify all details also.
 User

Login Page

User Home Page

Create New Files Read Files Update Files Delete Files

Database
2.2.3 GIVEN INPUT EXPECTED OUTPUT:
User Interface Design
Input : Enter Login name and Password (User, Router, CA, Publisher)
Output : If valid user name and password then directly open the home page otherwise show error message and
redirect to the registration page.

Admin
Input : Enter email and password , verify all details.
Output : Admin verify all user requests and accept user data then data send to user. Admin will verify all data status
and user feedback also.

Operator
Input : Operator Login name and Password
Output: If valid operator name and password then directly open the operator home page otherwise show error message
and redirect to the operator login page then verify user stored data and given permission to all files.

User
Input : Enter the name and password and stored data.
Output: If valid user name and password then directly open the user home page. All the resources added by user
options. User having some options create new files, read file, update file and delete file also. User verify all details also.
2.3 TECHNIQUE USED OR ALGORITHM USED

Algorithm: PRADA (Practical Approach for data handling)

The most important modifications of PRADA involve the CRUD (create, read, update, delete) operations.
Create: The coordinator first checks whether a create request is accompanied by DHRs.
Read.: Processing read requests in PRADA is performed.
Update: The update of already stored data involves the (potentially partial) update of stored data as well as the possible update of
associated DHRs.
Delete: Delete requests are processed analogously to read Requests.
 
Load balance metric: Intuitively, a good load balancing aims at all nodes being (nearly) equally loaded, i.e., the imbalance between the
load of nodes should be minimized. While underloaded nodes constitute a waste of resources, overloaded nodes drastically decrease the
overall performance of the cloud storage system.
Load balancing in PRADA: Key-value based cloud storage systems achieve a reasonably balanced load in two steps: (i) Equal
distribution of data at insert time, e.g., by applying a hash function to identifier keys, and (ii) re-balancing the cluster if absolutely
necessary by moving data between nodes. More advanced systems support additional mechanisms, e.g., load balancing over geographical
regions.
Since our focus in this paper lies on proving the general feasibility of supporting data compliance in cloud storage, we focus on the
properties of key-value based storage.
 CHAPTER 3
REQUIREMENTS ENGINEERING
3.1 GENERAL
Security Our goal is to provide a secure execution environment that provides a confidentiality
service to sensitive program logic in cloud applications, so the applications released to cloud
marketplaces are protected from malicious cloud users who attempt to commit software thefts.

3.2 HARDWARE REQUIREMENTS

The hardware requirements may serve as the basis for a contract for the implementation of the
system and should therefore be a complete and consistent specification of the whole system. They are used by
software engineers as the starting point for the system design. It shoals what the system do and not how it
should be implemented.

HARDWARE
PROCESSOR : PENTIUM IV 2.6 GHz, Intel Core 2 Duo.
RAM : 512 MB DD RAM
MONITOR : 15” COLOR
HARD DISK : 40 GB
3.3 SOFTWARE REQUIREMENTS

The software requirements document is the specification of the system. It should include both a definition
and a specification of requirements. It is a set of what the system should do rather than how it should do it. The
software requirements provide a basis for creating the software requirements specification. It is useful in
estimating cost, planning team activities, performing tasks and tracking the teams and tracking the team’s
progress throughout the development activity.

FRONT END : J2EE (JSP, SERVLET)

BACK END : MY SQL 5.5 OR MS SQL SERVER
OPERATING SYSTEM : WINDOWS 7
IDE : ECLIPSE
3.3 FUNCTIONAL REQUIREMENTS
A functional requirement defines a function of a software-system or its component. A function is described as a set of inputs,
the behaviour, and outputs. The outsourced computation is data is more secured.

Admin
• User request
• All Users Details
• Feed Back

Operator
• Files Request
• Read Files
• Update Request
• Delete Request
• Deleted Files Details

User
• Create New File
• Read File
• Update File
• Delete File

 
QR code embedded with the Payload and Extraction
 Send Message and Encrypt the payload
 Scramble the encrypted payload
 QR Code Generator
 Read the generated QR Code and get the normal message
 QR Code Generator
 Unscramble the scrambled payload and Decrypt the payload and
 Accept Messages from Users and View Ordinary QR Code
3.5 NON FUNCTIONAL REQUIREMENTS
The major non-functional Requirements of the system are as follows
Usability
The system is designed with completely automated process hence there is no or less user intervention.
Reliability
The system is more reliable because of the qualities that are inherited from the chosen platform java. The code built
by using java is more reliable.
Performance
This system is developing in the high level languages and using the advanced front-end and back-end technologies
it will give response to the end user on client system with in very less time.
Supportability
The system is designed to be the cross platform supportable. The system is supported on a wide range of hardware
and any software platform, which is having JVM, built into the system.
Implementation
The system is implemented in web environment using struts framework. The apache tomcat is used as the web
server and windows xp professional is used as the platform. Interface the user interface is based on Struts provides
HTML Tag
 CHAPTER 4
DESIGN ENGINEERING
4.1 GENERAL

Design Engineering deals with the various UML [Unified Modelling language] diagrams for the
implementation of project. Design is a meaningful engineering representation of a thing that is to be built.
Software design is a process through which the requirements are translated into representation of the software.
Design is the place where quality is rendered in software engineering. Design is the means to accurately
translate customer requirements into finished product.
4.1.1 USE CASE DIAGRAM:

Register

User Login

User Request

Accept Users

Database
Admin
Upload Files

Read Files

Update Files
Operator

Delete Files
4.1.2 Class diagram:

Admin
Register
Login
Login Name
UserRequest
Password
UserAcceptDetails Email
PhoneNumber
Password
EmailId
login()
Address
requests() login()
responses()
register()
accept()

User
Operator Register
Login
Login
View
ViewDetails
Database Upload
Check
Read
UploadRequest AdminDetails
Update
ReadRequest OperatorDetails
Delete
UpdateRequest UserDetails
DeleteRequest
register()
request()
login()
Login() response()
view()
request()
upload()
response()
read()
view()
update()
delete()
4.1.3 OBJECT DIAGRAM:

Admin : Admin Login : Login Register : Register

Database : Database

Operator : Operator User : User

4.1.4 State Diagram

Register / Login

Admin Operator User

Upload files request Uplodad files

User requests

Read files request Read files

Accept requests

Update files request Update files

User details

Delete files requests Delete files

Database
4.1.5 Sequence Diagram:

User Admin Operator Database

User Register
User Register Successfully

User request send to admin

Admin Login

Admin Login Successfully

User request details

Accept users

Upload file request

File uploaded
Read file request

Read files successfully

Updated file
Updated files successully
Delete files
Delete files successfully

Result
4.1.6 COLLABORATION DIAGRAM :

4: Admin Login
6: User request details
Admin Database

5: Admin Login Successfully

1: User Register

9: File uploaded
11: Read files successfully
13: Updated files successully
3: User request send to admin 15: Delete files successfully
2: User Register Successfully
7: Accept users
16: Result
8: Upload file request
10: Read file request
12: Updated file
14: Delete files
User Operator
4.1.7 Activity Diagram 

Register / Login

Admin Operator User

User Requests Upload Files Request Upload Files

Accept Users Read Files Request Read Files

View Details Update Files Request Update Files

Delete Files Request Delete Files

Dataabase
4.1.8 COMPONENT DIAGRAM

Admin Login Register

Operator Database User

Upload Files Update Files Delete Files

Read Files
4.1.9 E-R DIAGRAM

User
Admin
UID Email
Register

PWD
Login
PWD
Login

View Request
Details Data
Files

Name
Verify Operator
Acceptances Send
Requirement
s

Request &
Response
Database
4.1.10 Data Flow Diagram:
LEVEL 0:

User Page

User Login Server

Page

Error
Message

Database
LEVEL 1:

User

Login Page

User Home Page

Create New Files Read Files Update Files Delete Files

Database
4.1.11 DEPLOYMENT DIAGRAM

Admin Login Register

Database

Operator User
4.2 SYSTEM ARCHITECTURE:
 

Register &
User Create Files Delete Files
Login

Home Page Read & Update Files Send to operator

Operator Login
Users request

Upload & Read

Checking Database
Time
Router Home Details
Update & Delete
Page

Status & Feedback

Admin Login
User request
View All
Data
Home Page
User

Accept users
 CHAPTER 7
SNAPSHOTS

7.1 GENERAL:
This project is implements like web application using COREJAVA and the Server process is
maintained using the SOCKET & SERVERSOCKET and the Design part is played by Cascading
Style Sheet.

7.2 VARIOUS SNAPSHOTS

 CHAPTER 8
 SOFTWARE TESTING
 
8.1 GENERAL
The purpose of testing is to discover errors. Testing is the process of trying to discover every conceivable fault or
weakness in a work product. It provides a way to check the functionality of components, sub assemblies, assemblies and/or a
finished product It is the process of exercising software with the intent of ensuring that the Software system meets its
requirements and user expectations and does not fail in an unacceptable manner. There are various types of test. Each test
type addresses a specific testing requirement.
 
8.2 DEVELOPING METHODOLOGIES
The test process is initiated by developing a comprehensive plan to test the general functionality and special features
on a variety of platform combinations. Strict quality control procedures are used. The process verifies that the application
meets the requirements specified in the system requirements document and is bug free. The following are the considerations
used to develop the framework from developing the testing methodologies.
8.3 Types of Tests
8.3.1 Unit testing
Unit testing involves the design of test cases that validate that the internal program logic is functioning properly, and
that program input produce valid outputs. All decision branches and internal code flow should be validated. It is the testing of
individual software units of the application .it is done after the completion of an individual unit before integration. This is a
structural testing, that relies on knowledge of its construction and is invasive. Unit tests perform basic tests at component
level and test a specific business process, application, and/or system configuration. Unit tests ensure that each unique path of
a business process performs accurately to the documented specifications and contains clearly defined inputs and expected
results.

8.3.2 Functional test

Functional tests provide systematic demonstrations that functions tested are available as specified by the business and
technical requirements, system documentation, and user manuals.
Functional testing is centered on the following items:
Valid Input : identified classes of valid input must be accepted.
Invalid Input : identified classes of invalid input must be rejected.
Functions : identified functions must be exercised.
Output : identified classes of application outputs must be exercised.
Systems/Procedures: interfacing systems or procedures must be invoked.
8.3.3 System Test
System testing ensures that the entire integrated software system meets requirements. It tests a configuration to
ensure known and predictable results. An example of system testing is the configuration oriented system integration test.
System testing is based on process descriptions and flows, emphasizing pre-driven process links and integration points.

8.3.4 Performance Test

The Performance test ensures that the output be produced within the time limits, and the time taken by the system
for compiling, giving response to the users and request being send to the system for to retrieve the results.

8.3.5 Integration Testing

Software integration testing is the incremental integration testing of two or more integrated software components
on a single platform to produce failures caused by interface defects.
The task of the integration test is to check that components or software applications, e.g. components in a software
system or – one step up – software applications at the company level – interact without error.
8.3.6 Acceptance Testing
User Acceptance Testing is a critical phase of any project and requires significant participation by the end user. It also
ensures that the system meets the functional requirements.

Acceptance testing for Data Synchronization:

•The Acknowledgements will be received by the Sender Node after the Packets are received by the Destination Node
•The Route add operation is done only when there is a Route request in need
•The Status of Nodes information is done automatically in the Cache Updating process

8.3.7 Build the test plan

Any project can be divided into units that can be further performed for detailed processing. Then a testing strategy for
each of this unit is carried out. Unit testing helps to identity the possible bugs in the individual component, so the component
that has bugs can be identified and can be rectified from errors.
 CHAPTER 10
CONCLUSION & REFERENCES

10.1 CONCLUSION:

Accounting for compliance with data handling requirements (DHRs), i.e., offering control over where and how data is stored in the
cloud, becomes increasingly important due to legislative, organizational, or customer demands. Despite these incentives, practical solutions
to address this need in existing cloud storage systems are scarce. In this paper, we proposed PRADA, which allows clients to specify a
comprehensive set of fine-grained DHRs and enables cloud storage operators to enforce them. Our results show that we can indeed achieve
support for DHRs in cloud storage systems. Of course, the additional protection and flexibility offered by DHRs comes at a price: We
observe a moderate increase for query completion times, while achiev-ing constant storage overhead and upholding a near optimal storage
load balance even in challenging scenarios.
Importantly, however, data without DHRs is not impaired by PRADA. When a responsible node receives a request for data without
DHRs, it can locally check that no DHRs apply to this data: For create requests, the INSERT statement either contains DHRs or not, which
can be checked efficiently and locally. In contrast, for read, update, and delete requests, PRADA performs a simple and local check whether
a reference to a target node for this data exists. The overhead for this step is comparable to executing an if statement and hence negligible.
Only if a reference exists, which implies that the data was inserted with DHRs, PRADA induces overhead. Our extensive evaluation con-
firms that, for data without DHRs, PRADA shows the same query completion times, storage overhead, and bandwidth consumption as an
unmodified Cassandra system in all considered settings (indistinguishable results for Cassandra and PRADA* in Figures 5 to 8.)
Consequently, clients can choose (even at a granularity of individual data items), if DHRs are worth a modest performance decrease.