Balancing Document
-
Upload
siva-krishna-prasad-arja -
Category
Documents
-
view
219 -
download
0
Transcript of Balancing Document
![Page 1: Balancing Document](https://reader030.fdocuments.us/reader030/viewer/2022021317/577cbffd1a28aba7118e9717/html5/thumbnails/1.jpg)
8/9/2019 Balancing Document
http://slidepdf.com/reader/full/balancing-document 1/17
![Page 2: Balancing Document](https://reader030.fdocuments.us/reader030/viewer/2022021317/577cbffd1a28aba7118e9717/html5/thumbnails/2.jpg)
8/9/2019 Balancing Document
http://slidepdf.com/reader/full/balancing-document 2/17
demand resources making it an attractive environment for highly scalable, multi tiered
applications. 'owever, this can create additional challenges for back-end, transactional database
systems, which were designed without elasticity in mind. (espite the efforts o f key-value stores
like !mazon)s *imple(+, (ynamo, and oogle)s +igtable to provide scalable access to huge
amounts of data, transactional guarantees remain a bottleneck. To provide scalability and
elasticity, cloud services often make heavy use of replication to ensure consistent performance
and availability. !s 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. This makes it difficult to strictly
maintain the !$I( guarantees, as the $ /consistency0 part of !$I( is sacrificed to provide
reasonable availability. In systems that host sensitive resources, accesses are protected via
authorization policies that describe the conditions under which users should be permitted access
to resources. These policies describe relationships between the system principles, as well as the
certified credentials that users must provide to attest to their attributes. In a transactional
database system that is deployed in a highly distributed and elastic system such as the cloud,
policies would typically be replicated very much like data among multiple sites, often following
the same weak or eventual consistency model. It therefore becomes possible for a policy-based
authorization system to make unsafe decisions using stale policies. Interesting consistency
problems can arise as transactional database systems are deployed in cloud environments and use
policy-based authorization systems to protect sensitive resources. In addition to handling
consistency issues among database replicas, we must also handle two types of security
inconsistency conditions. %irst, the system may suffer from policy inconsistencies during policy
![Page 3: Balancing Document](https://reader030.fdocuments.us/reader030/viewer/2022021317/577cbffd1a28aba7118e9717/html5/thumbnails/3.jpg)
8/9/2019 Balancing Document
http://slidepdf.com/reader/full/balancing-document 3/17
updates due to the relaxed consistency model underlying most cloud services. In this paper, we
address this confluence of data, policy, and credential inconsistency problems that can emerge as
transactional database systems are deployed to the cloud.
LITRATUR R!I"
nforcing Policy and Data Consistency of Cloud Transactions
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 a policy - based authorization systems to
make unsafe decisions that might threaten sensitive resources. This paper highlights the
criticality of the problem. It then presents the first formalization of the concept of trusted
transactions when dealing with proofs of authorizations. !ccordingly, it defines different levels
of policy consistency constraints and present different enforcement approaches to guarantee the
trustworthiness of transactions executing on cloud servers. It proposed a Two-"hase #alidation
$ommit protocol as a solution, that is a modified version of the basic Two-"hase $ommit
protocols. It finally provides performance analysis of the different presented approaches to guide
the decision makers in which approach to use.
lasTraS# An lastic Transactional Data Store in t$e Cloud
&ver the last couple of years, $loud $omputing or 1lastic $omputing has emerged
as a compelling and successful paradigm for internet scale computing. &ne of the major
contributing factors to this success is the elasticity of resources. In spite of the elasticity provided
![Page 4: Balancing Document](https://reader030.fdocuments.us/reader030/viewer/2022021317/577cbffd1a28aba7118e9717/html5/thumbnails/4.jpg)
8/9/2019 Balancing Document
http://slidepdf.com/reader/full/balancing-document 4/17
by the infrastructure and the scalable design of the applications, the elephant /or the underlying
database0, which drives most of these web-based applications, is not very elastic and scalable,
and hence limits scalability. This paper, propose 1lasTra* which addresses this issue of
scalability and elasticity of the data store in a cloud computing environment to leverage from the
elastic nature of the underlying infrastructure, while providing scalable transactional data access.
This paper aims at providing the design of a system in progress, high-lighting the major design
choices, analyzing the different guarantees provided by the system, and identifying several
important challenges for the research community striving for computing in the cloud.
Data %anagement in t$e Cloud# Limitations and O&&ortunities
2ecently the cloud computing paradigm has been receiving significant excitement and
attention in the media and blogosphere. To some, cloud computing seems to be little more than a
marketing umbrella, encompassing topics such as distributed computing, grid computing, utility
computing, and software-as-a-service, that have already received significant research focus and
commercial implementation. 3onetheless, there exist an increasing number of large companies
that are offering cloud computing infrastructure products and services that do not entirely
resemble the visions of these individual component topics. This article discussed the limitations
and opportunities of deploying data management issues on these emerging cloud computing
platforms /e.g., !mazon eb *ervices0. It speculate that large scale data analysis tasks, decision
support systems, and application specific data marts are more likely to take advantage of cloud
computing platforms than operational, transactional database systems /at least initially0. It
present a list of features that a (+4* designed for large scale data analysis tasks running on an
!mazon-style offering should contain. It discuss some currently available open source and
commercial database options that can be used to perform such analysis tasks, and conclude that
![Page 5: Balancing Document](https://reader030.fdocuments.us/reader030/viewer/2022021317/577cbffd1a28aba7118e9717/html5/thumbnails/5.jpg)
8/9/2019 Balancing Document
http://slidepdf.com/reader/full/balancing-document 5/17
none of these options, as presently architected, match the re5uisite features. It expressed the need
for a new (+4*, designed specifically for cloud computing environments.
Automated Trust Negotiation Using Cry&togra&$ic Credentials
In automated trust negotiation /!T30, two parties exchange digitally signed credentials
that contain attribute information to establish trust and make access control decisions. +ecause
the information in 5uestion is often sensitive, credentials are protected according to access
control policies. In traditional !T3, credentials are transmitted either in their entirety or not at
all. This approach can at times fail unnecessarily, either because a cyclic dependency makes
neither negotiator willing to reveal her credential before her opponent, because the opponent
must be authorized for all attributes packaged together in a credential to receive any of them, or
because it is necessary to fully disclose the attributes, rather than merely proving they satisfy
some predicate /such as being over 67 years of age0. 2ecently, several cryptographic credential
schemes and associated protocols have been developed to address these and other problems.
'owever, they can be used only as fragments of an !T3 process. This paper introduces a
framework for !T3 in which the diverse credential schemes and protocols can be combined,
integrated, and used as needed. ! policy language is introduced that enables negotiators to
specify authorization re5uirements that must be met by an opponent to receive various amounts
of information about certified attributes and the credentials that contain it. The language also
supports the use of uncertified attributes, allowing them to be re5uired as part of policy
satisfaction, and to place their /automatic0 disclosure under policy control.
![Page 6: Balancing Document](https://reader030.fdocuments.us/reader030/viewer/2022021317/577cbffd1a28aba7118e9717/html5/thumbnails/6.jpg)
8/9/2019 Balancing Document
http://slidepdf.com/reader/full/balancing-document 6/17
OACerts# O'li(ious Attri'ute Certificate
This paper proposed &blivious !ttribute $ertificates /&!$erts0, an attribute certificate
scheme in which a certificate holder can select which attributes to use and how to use them. In
particular, a user can use attribute values stored in an &!$ert obliviously, i.e., the user obtains a
service if and only if the attribute values satisfy the policy of the service provider, yet the service
provider learns nothing about these attribute values. This way, the service provider)s access
control policy is enforced in an oblivious fashion. To enable the oblivious access control using
&!$erts, it proposed a new cryptographic primitive called &blivious $ommitment-+ased
1nvelope /&$+10. In an &$+1 scheme, +ob has an attribute value committed to !lice and !lice
runs a protocol with +ob to send an envelope /encrypted message0 to +ob such that8 /70 +ob can
open the envelope if and only if his committed attribute value satisfies a predicate chosen by
!lice, /60 !lice learns nothing about +ob)s attribute value. It develops provably secure and
efficient &$+1 protocols for the "edersen commitment scheme and comparison predicates as
well as logical combinations of them.
Distri'uted Pro(ing in Access)Control Systems
This paper presents a distributed algorithm for assembling a proof that a re5uest satisfies
an access-control policy expressed in a formal logic, in the tradition of 9ampson et al. It show
analytically that our distributed proof-generation algorithm succeeds in assembling a proof
whenever a centralized prover utilizing remote certificate retrieval would do so. In addition, we
show empirically that our algorithm outperforms centralized approaches in various measures of
performance and usability, notably the number of remote re5uests and the number of user
interruptions. It shows that when combined with additional optimizations including caching and
![Page 7: Balancing Document](https://reader030.fdocuments.us/reader030/viewer/2022021317/577cbffd1a28aba7118e9717/html5/thumbnails/7.jpg)
8/9/2019 Balancing Document
http://slidepdf.com/reader/full/balancing-document 7/17
automatic tactic generation, which it introduce here, our algorithm retains its advantage, while
achieving practical performance. %inally, it briefly describes the utilization of these algorithms as
the basis for an access-control framework being deployed for use at this institution.
Policy)'ased Access Control for "ea*ly Consistent Re&lication
1nforcing authorization policy for operations that read and write distributed datasets can
be tricky under the simplest of circumstances. 1nforcement is too often dependent on
implementation specifics and on policy detail that is inextricable from the data under
management. hen datasets are distributed across replicas in a weakly-consistent fashion, for
example when updates to policy and data propagate lazily, the problem becomes substantially
harder. *pecifically, if disjoint replicas can make different decisions about the permissibility of a
potential modification due to temporary policy inconsistencies, then permanently divergent state
can result. This paper describes and evaluates the design and implementation of an access-
control system for weakly consistent replication where peer replicas are not uniformly trusted.
This system allows for the specification of fine-grained access control policy over a collection of
replicated items. "olicies are expressed using a logical assertion framework and access control
decisions are logical proofs. "olicy can grow organically to encompass new replicas through
delegation. 1ventual consistency is preserved despite the fact that access control policy can be
temporarily inconsistent.
!enus# !erification for Untrusted Cloud Storage
This paper presents #enus, a service for securing user interaction with un trusted cloud
storage. *pecifically, #enus guarantees integrity and consistency for applications accessing a
key-based object store service, without re5uiring trusted components or changes to the storage
![Page 8: Balancing Document](https://reader030.fdocuments.us/reader030/viewer/2022021317/577cbffd1a28aba7118e9717/html5/thumbnails/8.jpg)
8/9/2019 Balancing Document
http://slidepdf.com/reader/full/balancing-document 8/17
![Page 9: Balancing Document](https://reader030.fdocuments.us/reader030/viewer/2022021317/577cbffd1a28aba7118e9717/html5/thumbnails/9.jpg)
8/9/2019 Balancing Document
http://slidepdf.com/reader/full/balancing-document 9/17
communication for every operation, a malicious service could simply ignore write operations by
some clients and respond to other clients with outdated data. These solutions guarantee integrity,
and by adding some extra out-of-band communication among the clients can also be used to
achieve a related notion of consistency. 'owever, they also incur a major drawback that hampers
system availability. *pecifically, even when the service functions correctly, all these protocols
may sometimes block a client during an operation, re5uiring the client to wait for another client
to finish, and do not guarantee that every client operation successfully completes. It has been
shown that this limitation is inherent.
+ISTIN S-ST%#
• To protect user access patterns from a cloud data store, illiams et al. introduce a
mechanism by which cloud storage users can issue encrypted reads, writes, and inserts.
%urther, illiams et al. propose a mechanism that enables un trusted service providers to
support transaction serialization, backup, and recovery with full data confidentiality and
correctness.
• ! dynamic consistency rationing mechanism that automatically adapts the level of
consistency at runtime. +oth of these works focus on data consistency, while our work
focuses on attaining both data and policy consistency.
• "roofs of data possession have been proposed as a means for clients to ensure that service
providers actually maintain copies of the data that they are contracted to host. In other
works, data replications have been combined with proofs of retrieve ability to provide
users with integrity and consistency guarantees when using cloud storage.
• $loudT"* is primarily concerned with providing consistency and isolation upon data
without regard to considerations of authorization policies.
![Page 10: Balancing Document](https://reader030.fdocuments.us/reader030/viewer/2022021317/577cbffd1a28aba7118e9717/html5/thumbnails/10.jpg)
8/9/2019 Balancing Document
http://slidepdf.com/reader/full/balancing-document 10/17
• This work proactively ensures that data stored at a particular site conforms to the policy
stored at that site. If the policy is updated, the server will scan the data items and throw
out any that would be denied based on the revised policy.
• The consistency of distributed proofs of authorization has previously been studied,
though not in a dynamic cloud environment. This work highlights the inconsistency
issues that can arise in the case where authorization policies are static, but the credentials
used to satisfy these policies may be revoked or altered.
• The authors develop protocols that enable various consistency guarantees to be enforced
during the proof construction process to minimize these types of security issues.
• Disad(antages# This 1xisting orks only focus on data consistency. It does not focus on
policy consistency. This work only concerns itself with local consistency of a single node,
not with transactions that span multiple nodes. This work highlights the inconsistency
issues that can arise in the case where authorization policies are static, but the credentials
used to satisfy these policies may be revoked or altered.
PROPOSD S-ST%#
• In this paper highlight the criticality of the problem. It defines the notion of trusted
transactions when dealing with proofs of authorization. !ccordingly, it propose several
increasingly stringent levels of policy consistency constraints, and present different
enforcement approaches to guarantee the trustworthiness of transactions executing on
cloud servers.
• It proposed a Two-"hase #alidation $ommit protocol as a solution, which is a modified
version of the basic Two-"hase #alidation $ommit protocols.
• It 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.
![Page 11: Balancing Document](https://reader030.fdocuments.us/reader030/viewer/2022021317/577cbffd1a28aba7118e9717/html5/thumbnails/11.jpg)
8/9/2019 Balancing Document
http://slidepdf.com/reader/full/balancing-document 11/17
• In this paper address this confluence of data, policy, and credential inconsistency
problems that can emerge as transactional database systems are deployed to the cloud.
• This paper formalized the concept of trusted transactions. Trusted transactions are those
transactions that do not violate credential or policy inconsistencies over the lifetime of
the transaction.
• It present a more general term, safe transactions, that identifies transactions that are both
trusted and conforms to the !$I( properties of distributed database systems.
• It defines several different levels of policy consistency constraints and corresponding
enforcement approaches that guarantee the trustworthiness of transactions executing on
cloud servers.
• It proposed a Two-"hase #alidation $ommit /6"#$0 protocol that ensures that a
transaction is safe by checking policy, credential, and data consistency during transaction
execution.
• Ad(antages# It provides a good balance between accuracy and performance, at the cost
of higher code complexity.
.ARD"AR R/UIR%NTS
Processor Ty&e # "entium I#
S&eed # 6.@ 'A
RA% # 6BC 4+
.ard dis* # 6D +
0ey'oard # 7D7E7D6 *tandard Feys
%ouse # *croll 4ouse
![Page 12: Balancing Document](https://reader030.fdocuments.us/reader030/viewer/2022021317/577cbffd1a28aba7118e9717/html5/thumbnails/12.jpg)
8/9/2019 Balancing Document
http://slidepdf.com/reader/full/balancing-document 12/17
SO1T"AR R/UIR%NTS
2 O&erating System # indows G
2 Programming Pac*age # 3et +eans I(1 G.:.7
2 Coding Language # H(F 7.G2 Data'ase # *9 *erver 6DDB
S-ST% ARC.ITCTUR
%ODULS
7. $loud %ormation
6. (ata &wner 2egister with !uthorization "olicies:. ;pload %ile
@. *afe Transaction
B. (ownload %ile
CLOUD 1OR%ATION#
![Page 13: Balancing Document](https://reader030.fdocuments.us/reader030/viewer/2022021317/577cbffd1a28aba7118e9717/html5/thumbnails/13.jpg)
8/9/2019 Balancing Document
http://slidepdf.com/reader/full/balancing-document 13/17
• %irst create a cloud infrastructure. It 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.
• ;sers interact with the system by submitting 5ueries or update re5uests encapsulated in
!$I( transactions. ! transaction is submitted to a Transaction 4anager /T40 that
coordinates its execution.
• 4ultiple T4s could be invoked as the system workload increases for load balancing, but
each transaction is handled by only one T4.
• It denote by the set of all credentials, which are issued by the $ertificate !uthorities
/$!s0 within the system. 'ere each $! offers an online method that allows any server to
check the current status of credentials.
DATA O"NR RISTRD "IT. AUT.ORI3ATION POLICIS#
• 3ext (ata &wner 2egistered with authorization policies, valid date from and valid date to
in desirable Trusted Third "arty or $!.
• This Trusted Third "arty or $! allows any server to check the current status of
credentials.
• Then the $! creates secret keys for each data owner and end user. +ecause this *ecret
Feys are used to !uthentication "urpose.
• ! (ata &wner wants to upload his file and end user wants to download a file, both are
used this secret key for encryption and decryption.
UPLOAD 1IL#
• (ata &wner wants to upload a file. *o he encrypted this file using T!)s secret Fey.
• %irst he sends a key re5uest to Trusted Third "arty.
• Trusted Third "arty creates a secret key and provide to (ata &wner.
• Then the data owner encrypts his file using this secret key.
![Page 14: Balancing Document](https://reader030.fdocuments.us/reader030/viewer/2022021317/577cbffd1a28aba7118e9717/html5/thumbnails/14.jpg)
8/9/2019 Balancing Document
http://slidepdf.com/reader/full/balancing-document 14/17
![Page 15: Balancing Document](https://reader030.fdocuments.us/reader030/viewer/2022021317/577cbffd1a28aba7118e9717/html5/thumbnails/15.jpg)
8/9/2019 Balancing Document
http://slidepdf.com/reader/full/balancing-document 15/17
the participant server has three values to report 70 the J1* or 3& reply for the
satisfaction of integrity constraints as in 6"$, 60 the T2;1 or %!9*1 reply for the
satisfaction of the proofs of authorizations as in 6"#, and :0 the version number of the
policies used to build the proofs as in 6"#.
• The process for the T4 under view consistency. It is similar to that of 6"# with the
exception of handling the J1* or 3& reply for integrity constraint validation and having
a decision of $&44IT rather than $&3TI3;1. The T4 enforces the same behavior as
6"# in identifying policies inconsistencies and sending the ;pdate messages. The same
changes to 6"# can be made here to provide global consistency by consulting the master
policies server for the latest policy version.
DO"NLOAD 1IL#
• !n end ;ser wants to access this upload file, he give the download re5uest to particular
(+)s *erver.
• This re5uest contains filename, data owner and so on.
•The particular *erver match this re5uest to its database then retrieve the result and
provide output to the user.
• %inally, the end users decrypt this file with data owner)s secret key and access this file.
![Page 16: Balancing Document](https://reader030.fdocuments.us/reader030/viewer/2022021317/577cbffd1a28aba7118e9717/html5/thumbnails/16.jpg)
8/9/2019 Balancing Document
http://slidepdf.com/reader/full/balancing-document 16/17
![Page 17: Balancing Document](https://reader030.fdocuments.us/reader030/viewer/2022021317/577cbffd1a28aba7118e9717/html5/thumbnails/17.jpg)
8/9/2019 Balancing Document
http://slidepdf.com/reader/full/balancing-document 17/17
:. (.H. !badi, (ata 4anagement in the $loud8 9imitations and &pportunities, I111 (ata
1ng. +ull., vol. :6, no. 7, pp. :-76, 4ar. 6DDL.@. H. 9i, 3. 9i, and .'. insborough, !utomated Trust 3egotiation ;sing $ryptographic
$redentials, "roc. 76th !$4 $onf. $omputer and $omm. *ecurity /$$* )DB0, 3ov.
6DDB.
B. H. 9i and 3. 9i, &!$erts8 &blivious !ttribute +ased $ertificates, I111 Trans.
(ependable and *ecure $omputing, vol. :, no. @, pp. :@D-:B6, &ct.-(ec. 6DDC.
C. 9. +auer et al., (istributed "roving in !ccess-$ontrol *ystems, "roc. I111 *ymp.
*ecurity and "rivacy, 4ay 6DDB.
G. T. obber, T.9. 2odeheffer, and (.+. Terry, "olicy-+ased !ccess $ontrol for eakly
$onsistent 2eplication, "roc. !$4 %ifth 1uropean $onf. $omputer *ystems /1uro*ys
)7D0, 6D7D.M. !. *hraer, $. $achin, !. $idon, I. Feidar, J. 4ichalevsky, and (. *haket, #enus8
#erification for ;ntrusted $loud *torage, "roc. !$4 orkshop $loud $omputing
*ecurity /$$* )7D0, 6D7D.