Contact at mumbai.academics@gmail.com or 8097636691
Responsive Ads Here

Friday, 2 February 2018

Balancing Performance Accuracy and Precision for Secure Cloud Transactions(2014)


Balancing Performance Accuracy and Precision for Secure Cloud Transactions(2014)

ABSTRACT:
In distributed transactional database systems deployed over cloud servers, entities cooperate to form proofs of authorizations that are justified by collections of certified credentials. These proofs and credentials may be evaluated and collected over extended time periods under the risk of having the underlying authorization policies or the user credentials being in inconsistent states. It therefore becomes possible for policy-based authorization systems to make unsafe decisions that might threaten sensitive resources. In this paper, we highlight the criticality of the problem. We then define the notion of trusted transactions when dealing with proofs of authorization. Accordingly, we propose several increasingly stringent levels of policy consistency constraints, and present different enforcement approaches to guarantee the trustworthiness of transactions executing on cloud servers. We propose a Two-Phase Validation Commit protocol as a solution, which is a modified version of the basic Two-Phase Validation Commit protocols. We finally analyze the different approaches presented using both analytical evaluation of the overheads and simulations to guide the decision makers to which approach to use.
EXISTING SYSTEM:
To provide scalability and elasticity, cloud services oftenmake heavy use of replication to  ensure consistent performance and availability. As a result, many cloud services rely on the notion of eventual consistency when propagating data throughout the system. This consistency model is a variant of weak consistency that allows data to be inconsistent among some replicas during the update process, but ensures that updates will eventually be propagated to all replicas.
DISADVANTAGES OF EXISTING SYSTEM:
Ø Consistency problems can arise as transactional database systems are deployed in cloud environments and use policy-based authorization systems to protect sensitive resources.
Ø The system may suffer from policy inconsistencies during policy updates.
Ø It is possible for external factors to cause user credential inconsistencies over the lifetime of a transaction.
PROPOSED SYSTEM:
Ø We formalize the concept of trusted transactions.
Ø We define several different levels of policy consistency constraints and corresponding enforcement approaches that guarantee the trustworthiness of transactions executing on cloud servers.
Ø We propose a Two-Phase Validation Commit (2PVC) protocol that ensures that a transaction is safe by checking policy, credential, and data consistency during transaction execution.
Ø We carry out an experimental evaluation of our proposed approaches.
ADVANTAGES OF PROPOSED SYSTEM:
Ø Identifies transactions that are both trusted and conform to the ACID properties of distributed database systems.
Ø Guarantee the trustworthiness of transactions executing on cloud servers.
Ø A transaction is safe by checking policy, credential, and data consistency during transaction execution.
Ø Most suitable in various situations.
MODULES:
1.     Server Module.
2.     Cloud User Module.
3.     Transaction Manager.
4.     Certificate Authorities.
MODULES DESCRIPTION:
Server Model
In this Module, We design a cloud infrastructure consisting of a set of servers, where each server is responsible for hosting a subset of all data items belonging to a specific application domain.
Cloud User Module
*       In this Module, Users interact with the system by submitting queries or update requests encapsulated in ACID transactions.
*       Since transactions are executed over time, the state information of the credentials and the policies enforced by different servers are subject to changes at any time instance, therefore it becomes important to introduce precise definitions for the different consistency levels that could be achieved within a transaction’s lifetime. These consistency models strengthen the trusted transaction definition by defining the environment in which policy versions are consistent relative to the rest of the system. Before we do that, we define a transaction’s view in terms of the different proofs of authorization evaluated during the lifetime of a particular transaction.
Transaction Manager
*       A transaction is submitted to a Transaction Manager(TM) that coordinates its execution. Multiple TMs could be invoked as the system workload increases for load balancing, but each transaction is handled by only one TM.
*       A common characteristic of most of our proposed approaches to achieve trusted transactions is the need for policy consistency validation at the end of a transaction. That is, in order for a trusted transaction to commit, its TM has to enforce either view or global consistency among the servers participating in the transaction.
Certificate Authorities
*       We use the set of all credentials, which are issued by the Certificate Authorities (CAs) within the system. We assume that each CA offers an online method that allows any server to check the current status of credentials that it has issued.
*       In this module, we provide a Safe transaction. A safe transaction is a transaction that is both trusted (i.e., satisfies the correctness properties of proofs of authorization) and database correct (i.e., satisfies the data integrity constraints).
*       In this module, also develop Two Phase Validation system. As the name implies, 2PV operates in two phases: collection and validation. During collection, the TM first sends a Prepare-to-Validate message to each participant server. In response to this message, each participant 1) evaluates the proofs for each query of the transaction using the latest policies it has available and 2) sends a reply back to the TM containing the truth value (TRUE/FALSE) of those proofs along with the version number and policy identifier for each policy used
SYSTEM REQUIREMENTS:
HARDWARE REQUIREMENTS:
Ø System                          :         Pentium IV 2.4 GHz.
Ø Hard Disk                      :         40 GB.
Ø Floppy Drive                 :         1.44 Mb.
Ø Monitor                         :         15 VGA Colour.
Ø Mouse                            :         Logitech.
Ø Ram                               :         512 Mb.
SOFTWARE REQUIREMENTS:
Ø Operating system           :         Windows XP/7.
Ø Coding Language          :         ASP.net, C#.net
Ø Tool                                   :         Visual Studio 2010
Ø Database                         :         SQL SERVER 2008

No comments:

Post a Comment