NZ618683B2 - Access control to data stored in a cloud - Google Patents
Access control to data stored in a cloud Download PDFInfo
- Publication number
- NZ618683B2 NZ618683B2 NZ618683A NZ61868312A NZ618683B2 NZ 618683 B2 NZ618683 B2 NZ 618683B2 NZ 618683 A NZ618683 A NZ 618683A NZ 61868312 A NZ61868312 A NZ 61868312A NZ 618683 B2 NZ618683 B2 NZ 618683B2
- Authority
- NZ
- New Zealand
- Prior art keywords
- rights
- application
- access
- server
- data
- Prior art date
Links
- 238000000034 method Methods 0.000 claims abstract description 61
- 230000009471 action Effects 0.000 claims description 22
- 238000004891 communication Methods 0.000 claims description 7
- 238000012546 transfer Methods 0.000 claims description 7
- 238000007726 management method Methods 0.000 description 23
- 238000012545 processing Methods 0.000 description 19
- 230000008569 process Effects 0.000 description 10
- 238000011161 development Methods 0.000 description 9
- 238000013459 approach Methods 0.000 description 8
- 230000015654 memory Effects 0.000 description 8
- 230000008901 benefit Effects 0.000 description 5
- 238000013475 authorization Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 4
- 230000008859 change Effects 0.000 description 2
- 230000008878 coupling Effects 0.000 description 2
- 238000010168 coupling process Methods 0.000 description 2
- 238000005859 coupling reaction Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000012946 outsourcing Methods 0.000 description 2
- 238000007639 printing Methods 0.000 description 2
- 241000700605 Viruses Species 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 230000001681 protective effect Effects 0.000 description 1
- 238000012502 risk assessment Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/25—Integrating or interfacing systems involving database management systems
- G06F16/252—Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
Abstract
method and a system (201) for accessing data (207) stored in a cloud (202) with a provider of the cloud; an entity (205, 208) which accesses the data; at least one rights application (206, 209) and a rights server (210) are disclosed. The rights server is not subject to the control of the cloud provider and comprises a rights policy. The rights policy can be used to define at least the following access rights of access rights of users and/or user groups or access rights of client and/or server applications. The entity which accesses the data can be a client application (208), a server application (205) or a user wishing to access the data using the client and/or server application. The method for accessing data (207) stored in a cloud (202) comprises (a) the rights application (206, 209) is asked whether access to the data by the accessing entity is allowed; (b) the rights application informs the rights server (210) of the requested access; (c) the rights server provides an item of access information which can be used to determine whether the requested access is allowed according to the access rights of the accessing entity and (d) the data (207) can be accessed only when access is allowed according to the access information. The access information can comprise access information comprises a rights policy and a key for decrypting the data. rovider and comprises a rights policy. The rights policy can be used to define at least the following access rights of access rights of users and/or user groups or access rights of client and/or server applications. The entity which accesses the data can be a client application (208), a server application (205) or a user wishing to access the data using the client and/or server application. The method for accessing data (207) stored in a cloud (202) comprises (a) the rights application (206, 209) is asked whether access to the data by the accessing entity is allowed; (b) the rights application informs the rights server (210) of the requested access; (c) the rights server provides an item of access information which can be used to determine whether the requested access is allowed according to the access rights of the accessing entity and (d) the data (207) can be accessed only when access is allowed according to the access information. The access information can comprise access information comprises a rights policy and a key for decrypting the data.
Description
Access control to data stored in a cloud
Description
The invention relates to a method for accessing data stored
in a cloud and to corresponding apparatuses.
The term “cloud computing” describes an approach for
dynamically providing abstracted information technology (IT)
infrastructures (for example computing capacity, data
memory, network capacities or else finished software) in a
manner adapted to the requirements via a network. From the
point of view of the user, the infrastructure provided
appears to be remote and opaque, like wrapped in a “cloud”.
With this approach, part of the IT landscape (in this
context, hardware such as the computing center, data memory
and software, for instance) is no longer operated on the
user side or provided at the user’s location but rather is
rented as a service from one or more providers, for example,
these providers being able to be geographically remote. The
applications or data are no longer situated (only) on the
local computer or a (company) computing center but rather in
the “cloud”. In this case, the cloud may be part of the
Internet or may comprise the latter.
Cloud computing makes it possible to provide network-based
applications in new business models. Services in the cloud
may be provided on different levels in this case:
(a) Infrastructure (IaaS):
A potential customer “rents” computing power in order
to implement his own services. For this purpose, cloud
computing uses computing centers which are either
concentrated at one location or can be interconnected
in a distributed manner in order to provide flexible
services.
7928180_1.doc
Virtual machines are implemented on these computers.
The customers load data (for example images) into the
cloud and processing is effected in the computing
center without user interaction.
(b) Platform (PaaS):
The customer gains access to a platform which
comprises, on the one hand, the infrastructure for
providing a service as well as particular software
parts (for example middleware) which can be used to
create services. The service created thereby is a web
application, for example.
(c) Software (SaaS):
A cloud provider provides a network-based application
which is used by the customer using his browser. In
this case, documents or data records can be created or
processed by the customer using the browser.
The outsourcing of applications and data may be a security
threat since data and documents are stored with the cloud
provider and - depending on the type of cloud or
implementation of the service - are also processed there
(that is to say these data are also accessed in the cloud).
For example, local system administrators of the service
operator (also referred to as cloud system administrators)
therefore have any desired access to the data if no special
protective measures are taken. In addition, other attacks on
the data are possible and the user who outsources his data
to the cloud does not know what security measures have been
taken for his data and whether they are effective. In other
words, the user cannot estimate or can only poorly estimate
the actual threat to his possibly confidential or sensitive
data.
Continuous protection of the data from unauthorized access
and, in particular, shielding from the system administrators
7928180_1.doc
(this is also referred to as “operator shielding”) are
important prerequisites for outsourcing critical (for
example security-relevant and/or confidential) data to the
cloud. Continuous protection which is independent of the
security measures provided by the cloud provider can be
achieved only when the owner of the data has control over
access to the data and the security measures required for
this purpose.
A document-based cloud application consists of a program
running on the server (also referred to as a server
application or AppS) and a program which runs locally with
the user (also referred to as a client application or AppC)
and typically runs in a web browser. In this case, depending
on the architecture, the division of software between the
server application and the client application may be scaled
or configured differently.
A widespread method for protecting data in cloud
applications is the encryption of the data. There are two
variants in this case:
(A) The encryption is carried out by the owner of the data
before documents are transferred to the cloud
application. The owner manages the corresponding keys.
The documents are continuously protected when being
transported to and from the cloud and during storage in
the cloud.
(B) The cloud application encrypts documents upon arrival
or when being stored on local data storage media inside
the cloud, the cloud provider managing a so-called
encryption key. The secure transport of the documents
should be explicitly ensured by using a secure channel
(for example using a secure hypertext transfer
protocol, “https”).
7928180_1.doc
In case (A), it is not possible to process the documents and
data in the cloud but only to purely store them. Useful
processing of documents is therefore possible, only after
decryption by a user, locally on his computer. The secure
management of the key material used which must be made
available to all authorized users who intend to view or
process the documents is problematic and complicated in this
case.
Since, in case (B), the encryption is carried out by means
of the rented software inside the cloud, there are points of
attack for circumventing the encryption for cloud system
administrators, for example. In order to securely implement
such a solution, known methods also require, in addition to
technical means, organizational measures which are usually
always a weak point. The owner of the data must therefore
place a considerable amount of trust in the cloud provider
as the operator of the cloud application to the effect that
the cloud provider securely implements an encryption
solution.
Known as digital rights management (DRM: Digital Rights
Management) is a system for companies, referred to as EDRM
(Enterprise Digital Rights Management), which provides
access protection for documents irrespective of their
storage location. A protected document can be opened and
processed by an authorized user only in accordance with his
access rights which are valid for this, irrespective of
where the document has been stored or how it has been
transmitted. An unauthorized user without access rights
cannot start anything with a copy of the document which he
has received by email, for example, or has discovered on a
USB stick.
However, in order to use EDRM, the applications must be
specifically adapted for it, that is to say they must be
supplemented with an EDRM functionality, since the basis of
EDRM is the encryption of documents. The publisher of a
7928180_1.doc
document encrypts the document before he releases it; the
publisher also additionally defines the rights for users
and/or groups for the document. The encrypted file including
the access rights is sent to an EDRM server.
In addition to the EDRM server which is the central part of
the EDRM approach, there is an EDRM client which must be
installed on every computer intended to process EDRM-
protected documents. The EDRM client communicates with the
EDRM server in order to determine the key and the rights of
a user with respect to a document. The EDRM server provides
the key only after the user has been authenticated with
respect to the EDRM server. The EDRM client transfers the
rights to an application which has EDRM capability and is
responsible for complying with the rights. The EDRM client
decrypts the document and carries out renewed encryption
which is possibly required later. The key is kept secret,
even from a user with administration rights, by the EDRM
client using code obfuscation and other technologies.
Fig. 1 shows an architecture of a known EDRM approach. An
EDRM client 101 is connected to an EDRM server 102. The EDRM
server is connected to a further EDRM client 103, for
example a computer belonging to a customer, a supplier or a
business partner. The EDRM clients 101, 103 and the EDRM
server may be functionalities (comprising hardware and/or
software) which are provided or installed on computers, for
example personal computers.
A (protected) document is created as follows:
(1) The author/owner creates the document.
(2) The author/owner encrypts the document with the aid of
the EDRM client 101 and specifies the access rights in
a format specified by the EDRM system, a so-called EDRM
policy. In this case, it is possible to describe and
allocate access rights in a detailed manner: for
example, it is possible to define for each authorized
person whether the latter can read, print, change or
7928180_1.doc
redistribute the document. A period of time during
which access is allowed can also be limited (for
example in a personal manner).
(3) The encrypted document is sent, together with the
rights, to the EDRM server 102.
The protected document is accessed as follows:
(1) A user loads the protected document into an application
(for example an application running locally on his
computer). He locally needs the EDRM client 103 for
access. This EDRM client 103 is connected to the local
device and to the user using cryptographic means.
(2) The EDRM client 103 contacts the EDRM server 102 which
responds with a request to authenticate the user.
(3) If the authentication is successful, the EDRM client
103 receives the rights object with the EDRM policy and
the decryption key.
(4) The EDRM client 103 decrypts the document and forwards
it to the application. Actions on the document such as
printing or processing are carried out by the
application only if the EDRM client 103 allows this
according to the rights specified in the EDRM policy.
This means that the application must be adapted to the
EDRM functionality.
It is possible to use existing EDRM solutions in connection
with a cloud and to thus protect documents by means of
encryption. EDRM can therefore be considered to be a
functionality which comprises an encryption method with key
management. In a similar manner to variants (A) and (B)
described above, the owner of the document can operate the
EDRM server 102 (and can therefore have the key management
under his control) or else the cloud provider can provide
the EDRM server 102.
With respect to the cloud application, documents can be
stored with EDRM protection, with the result that these
documents can be locally processed only by authorized users
7928180_1.doc
(according to the EDRM policy) on their device. The
following problems arise in this case:
(a) If documents are intended to be processed online by the
server application (AppS) (for example for editing a
document or for converting it into a PDF file),
corresponding reading or processing rights must be
granted to the server in known EDRM systems. All
processing operations which are carried out by the
server application are therefore carried out with the
EDRM authorization of the server, which must be
automatically granted, in particular without any
previous user authentication. This is a point of attack
which can be used, for example, by system
administrators or external attackers.
(b) Existing EDRM systems cannot distinguish between
processing by the server (for example search indexing
or checking for viruses) and processing by the
(authorized) user. Even if the processing is carried
out by an authorized user who edits a document, for
example, it is not possible to understand in the EDRM
system who has accessed the document since only access
by the server is entered in the corresponding log
entries on the EDRM server.
(c) The two parts of the application, that is to say the
server application and the client application, run in
different contexts, that is to say on the server and
locally on the user’s computer, with different security
requirements. Depending on the risk assessment, an
owner of a document will more likely allow processing
by the client application or else by the server
application, for example. Furthermore, depending on the
division of the application, it may be desirable for
the client application to be allocated different rights
than the server application. For example, a right for
printing a document is less useful for a server
7928180_1.doc
application than, for example, a right for converting
the document into a PDF file. Without a distinction
between the rights of the server application and the
client application, the semantics of some rights are
unclear, which may result in problems when specifying
the rights for a document.
The present invention provides a method for accessing data
stored in a cloud, with
- a provider of the cloud;
- an entity which accesses the data, the entity
comprising at least one of:
- a client application,
- a server application,
- a user wishing to access the data using the client
and/or server application;
- at least one rights application;
- a rights server which is not subject to the control
of the cloud provider and comprises a rights policy which
can be used to define at least the following access rights:
▪ access rights of users and/or user groups,
▪ access rights of client and/or server
applications,
having the following steps:
(a) the rights application is inquired whether access
to the data by the accessing entity is allowed;
(b) the rights application informs the rights server
of the requested access;
(c) the rights server provides an item of access
information which can be used to determine whether access is
allowed according to the access rights of the accessing
entity;
(d) the data can be accessed only when access is
allowed according to the access information.
The present invention further provides a system for
accessing data stored in a cloud, the system comprising at
least one of:
7928180_1.doc
- a provider of the cloud;
- an entity which accesses the data, the entity
comprising at least one of:
- a client application,
- a server application,
- a user wishing to access the data using the client
and/or server application;
- at least one rights application;
- a rights server which is not subject to the control
of the cloud provider and comprises a rights policy which
can be used to define at least the following access rights:
▪ access rights of users and/or user groups,
▪ access rights of client and/or server
applications;
the system configured to carry out the method defined
above.
The present invention further provides a cloud
infrastructure configured to carry out the method defined
above, which is designed in such a manner that the data can
be accessed only when access is allowed according to the
access information.
The present invention still further provides a rights server
configured to carry out the method defined above, which is
not subject to the control of the cloud provider, comprising
a rights policy which can be used to define at least the
following access rights:
▪ access rights of users,
▪ access rights of client and/or server applications.
Preferred embodiments can be gathered, in particular, from
the dependent claims.
An embodiment of the invention seeks to avoid one or more of
the abovementioned disadvantages and, in particular, to
specify an efficient solution for securely using data stored
in a cloud.
7928180_1.doc
Alternatively or additionally, an embodiment of the
invention seeks to at least provide the public with a useful
choice.
There is disclosed herein a method for accessing (in
particular for using) data stored in a cloud is proposed,
(a) in which a request for access to the data is
transmitted from a rights application to a rights
server,
(b) in which the rights server checks, on the basis of
the request from the rights application, whether
access to the data is allowed,
(c) in which, if access to the data is allowed, the
rights server provides the rights application with
an item of access information,
(d) in which the rights application accesses the data.
According to the explanations made in this document, the
cloud can be a resource (for example a partially generally
accessible or publicly accessible resource) in a network,
for example the Internet.
The cloud comprises data and an application. The services of
the cloud can be provided by a cloud provider.
Accordingly, no access to the data may be allowed or
explicit refusal or rejection may be effected if the check
revealed that access is not allowed.
The present solution enables finely graduated access control
to data or applications provided by a cloud, in particular
for document-based applications or database access
operations. In this case, access can be advantageously
effected under the supervision of an owner of the data or
applications.
7928180_1.doc
The rights application may be part of the server
application. In particular, the server application and the
rights application may be implemented inside the cloud, for
example with a cloud provider or in an environment
controlled by the latter.
It is additionally noted that two rights applications may be
provided, one rights application which is assigned to the
client application and one rights application which is
assigned to the server application.
One development is that, before step (a), a client
application is authenticated with a server application.
The server application may be an application of the cloud
provider. In this case, access to the data can be
coordinated using the server application. In particular, the
server application may be a database application which
accesses protected data (records) of a database in the
cloud. In particular, the data are stored in the cloud in
encrypted form and decryption is carried out using the
rights application described here.
Another development is that the rights application accesses
the data and forwards the latter to the server application.
For example, the database may have a database management
system which coordinates access to the data records. The
database management system may transmit encrypted data
records (or parts of data records) to the rights application
which carries out the decryption (if access is allowed). The
decrypted data may be transmitted to the server application,
for example, via the database management system or may be
transmitted to the server application directly. It is also
possible for the decrypted data to be transmitted to the
client application via the server application.
7928180_1.doc
In particular, one development is that the client
application transfers an authentication token to the server
application, which token is transmitted from the rights
application to the rights server in order to gain access to
the data.
A development is also that the client application transfers
a reference which is transmitted from the rights application
of the server to the rights server, the rights server
requesting and/or carrying out authentication on the basis
of the reference.
In particular, one development is that the reference is a
reference to a rights application of the client.
Furthermore, one development is that the rights application
is a rights application in a first environment and/or a
rights application in a second environment.
The first environment is, for example, an environment of a
company or a user, that is to say, in particular, a local
environment in which the client application can run and is
at least largely under the control of a user or user group.
In contrast, the second environment is an environment of the
cloud, for example an environment of a cloud provider. For
example, the second environment may be a publicly accessible
network, for example the Internet or part of the Internet.
The second environment is not subject to the user’s control.
For example, a distinction can be made between the rights of
a user on the local computer on which the client application
runs and the rights on the server on which the server
application runs. The respective rights can accordingly be
implemented differently by rights applications on the client
and the server.
7928180_1.doc
In this case, it is noted that the computer denotes any
desired computer, for example a portable computer or a
workstation computer or else a mobile terminal (for example
a mobile telephone, smart phone, digital assistant), a
tablet computer, etc. In principle, any device with which
“cloud computing” is possible can be referred to as a
computer.
Within the scope of an additional development, the rights
server is provided in the first environment.
It is thus advantageous for the rights server to be in the
trusted environment of the user, the user group or the
company. It can thus be ensured that the security-relevant
information is stored in the sphere of influence of the user
or client application. It is not possible to access
protected data without this information. This considerably
reduces the required trust which must be placed in the cloud
provider.
The rights application of the cloud, that is to say of the
cloud provider, communicates with the rights server via a
protected connection, for example, in order to obtain the
access information for accessing the security-relevant data
stored in the cloud. A cloud system administrator is not
able to view the data either without this access information
from the rights server.
A next development involves the request from the rights
application comprising at least one of the following items
of information:
- an item of user information,
- an item of computer information, in particular an
identification of a computer,
- an item of information for identifying the data
which are intended to be accessed.
One refinement is that the access information comprises:
7928180_1.doc
- a rights policy;
- a key for decrypting the data.
The rights policy relates to an agreement, for example
according to notation of a rights language, of who can do
what with which data and for how long. In this case,
different actions can be defined for different users, user
groups or computers. It is also possible, according to the
rights policy, for an operation to be able to be carried out
on the data without completely reading the data (for example
indexing of data records by the server).
An alternative embodiment involves the rights server
checking, on the basis of the request from the rights
application, whether access to the data is allowed by
carrying out a comparison with the rights policy previously
created for the data.
For example, a user or a user group can create data and can
provide the latter with particular rights for particular
users or user groups. The resultant rights policy is stored
on the rights server. This ensures that, during subsequent
access, only those users or computers with permission to do
so can access the data. Furthermore, the type of access to
the data can also be defined or restricted using the rights
policy.
A next refinement is that the rights policy comprises at
least one of the following items of information:
- an item of user or computer information,
- an action which can be carried out by the user or
computer,
- an action which cannot be carried out by the user or
computer,
- a validity period.
One advantage is that the rights policy can be used to
distinguish between rights of a user or a computer belonging
7928180_1.doc
to the user and rights of the server. Therefore, the user
can process the data without having to grant rights to the
server for this purpose.
Furthermore, it is also possible to use the rights policy to
grant particular rights to the server, with the result that
the latter can automatically carry out predefined tasks, for
example indexing files. These rights can be reduced to
minimum requirements by allowing access only to some of the
data, for example. This advantageously minimizes the
possibility for misuse by administrators of the cloud
application or by other external attackers.
A refinement is also that communication between the rights
server and the rights application is secure.
For example, communication or the connection between
components or processes can be secured by means of suitable
cryptographic methods or measures.
One development involves the rights server logging at least
some of the requests.
An additional refinement is that the data comprise:
- at least one document;
- at least one application;
- at least one database entry, in particular a
database.
In particular, the data may contain confidential or
partially confidential or other sensitive information. In
principle, there is great interest in storing data in the
cloud because accessibility is possible from everywhere, for
example via the Internet. The creation of backup copies or
the porting of data if a new computer is set up is also
dispensed with. In contrast, there is the disadvantage that
data stored once in the public network, in principle, can be
viewed, copied or used in another manner by unauthorized
7928180_1.doc
parties more easily than is the case with data stored
locally on a computer. The present approach provides a
solution here which involves using the advantages of cloud
computing and simultaneously ensuring increased protection
of personal or other confidential data.
There is also disclosed herein an apparatus for accessing
data stored in a cloud, comprising a processing unit which
is set up in such a manner that
(a) a request for access to the data can be
transmitted from a rights application to a rights
server,
(b) the rights server can check, on the basis of the
request from the rights application, whether
access to the data is allowed,
(c) if access to the data is allowed, the rights
server can provide the rights application with an
item of access information,
(d) the rights application can access the data.
The apparatus may be a component in the cloud, in particular
a component belonging to the cloud provider, or a local
component belonging to the user or to the company wishing to
use the cloud provider’s service. For example, the apparatus
may be a server on which the server application and the
rights application of the server run. The apparatus may also
be a local computer belonging to the user, on which the
client application and the rights application of the client
run. An option is also for the apparatus to be a computer on
which the rights server can (also) be operated. The
apparatus may be arranged, for example, in the first or
second environment explained above.
The processing unit may be, in particular, a processor unit
and/or an at least partially hard-wired or logical circuit
arrangement which is set up, for example, in such a manner
that the method can be carried out as described herein. Said
processing unit may be or comprise any type of processor or
7928180_1.doc
computer with accordingly required peripherals (memories,
input/output interfaces, input/output devices, etc.).
The above explanations relating to the method accordingly
apply to the apparatus. The apparatus may be configured in
one component or distributed in a plurality of components.
In particular, part of the apparatus may also be connected
via a network interface (for example the Internet).
The solution presented herein also comprises a computer
program product which can be loaded directly into a memory
of a digital computer, comprising program code parts which
are suitable for carrying out steps of the method described
here.
The abovementioned problem is also solved by means of a
computer-readable storage medium, for example any desired
memory, comprising instructions (for example in the form of
program code) which can be carried out by a computer and are
suitable for the computer to carry out steps of the method
described here.
The above-described properties, features and advantages and
the manner in which they are achieved become more clearly
and distinctly comprehensible in connection with the
following schematic description of exemplary embodiments
which are explained in more detail in connection with the
drawings. In this case, identical or identically acting
elements can be provided with the same reference symbols for
clarity.
In the description in this specification reference may be
made to subject matter which is not within the scope of the
appended claims. That subject matter should be readily
identifiable by a person skilled in the art and may assist
in putting into practice the invention as defined in the
presently appended claims.
7928180_1.doc
In the drawings:
fig. 2 shows a schematic overview of components of an
architecture for a document management system;
fig. 3 shows a schematic overview of components of an
architecture for accessing a database stored in a
cloud.
The present solution is based, in particular, on an EDRM
system or is an extension of a known EDRM system. A secure
way of handling data stored in a cloud is proposed, in which
case they may be different types of data. The scenarios of a
document management system and a database are described by
way of example below, that is to say for the case in which
documents or database entries are intended to be stored in
the cloud.
According to the definition mentioned in the introduction,
the cloud is a resource in a network, for example the
Internet, which is accessible to a multiplicity of users of
different stations or computers (for example personal
computers, laptops, mobile terminals, smart phones, personal
digital assistants, etc.) via wireless or wired interfaces.
In particular, the cloud comprises data (for example
documents, databases), applications for accessing the data
and data security components.
Fig. 2 shows a schematic overview of components of an
architecture for a document management system.
An environment 201 corresponds, for example, to a company
environment, for example a computer network belonging to a
company. A cloud 202 denotes an environment of an external
network, for example part of the Internet or a network which
is connected to the environment 201 via the Internet. For
example, the cloud 202 is provided by an external service
provider and makes it possible to flexibly access the data
7928180_1.doc
or programs stored in the cloud. The data may also be part
of programs which run locally on a computer connected to the
cloud 202.
The cloud 202 contains an environment 204 which corresponds
to an application environment provided by a service provider
(also referred to as a cloud provider). The environment 204
comprises a server application 205 and a rights application
206. A data memory 207 (for example in the form of a central
or decentralized database) is also provided in the cloud.
An environment 203 which corresponds to an individual
environment of a user is provided inside the environment
201. This may be, for example, a computer which belongs to
the user and is incorporated inside the environment 201. A
client application 208 and a rights application 209 are
provided in the environment 203. A rights server 210 is also
situated inside the environment 201.
The user can use the client application 208 to access the
server application 205 of the cloud 202.
The mechanisms of this approach are explained in more detail
below:
For example, a rights policy (for example in the form of an
EDRM policy language) is used and can be used to distinguish
between the rights of a user for processing documents in the
client application (AppC) and in the server application
(AppS), for example. The rights policy is, for example, an
agreement on particular rights for particular applications
and/or users for a predefined period of time, for example.
The rights policy may have the following format, for
example:
Document:
→ User 1: rights (AppS), rights (AppC); validity range
7928180_1.doc
→ User 2: rights (AppS), rights (AppC); validity range
→ Server: rights; validity range
Therefore, individual rights can be respectively allocated
and (possibly additionally) a duration for the validity of
the rights may be agreed for the document for user 1 and
user 2 and the server.
For example, a user on the local device with the client
application 208 could be granted only a right to view but
not to change or print. However, this user could be allowed
to process the document by means of the server application
205. In this case, processing may also comprise
comprehensive functions; for example, the user could cause
the document to be translated by the server application 205.
One example of a right which could be granted to the server
application 205 is the indexing of documents. In this case,
the server could be granted read access only to a respective
particular section of a document containing keywords, with
the entire document, including the part with the keywords
(which itself can be sensitive information), being
protected.
Which rights are allocated depends, for example, on the
functionality of the application and its architecture, in
particular also on a division of functions between the
client application 208 and the server application 205.
If a document is processed by a user using the client
application 208 (that is to say the document is loaded into
the memory of the local device and is therefore loaded into
the environment 203), it may be useful to allow only
processing by this client application 208. If, in contrast,
the document is processed by the server application 205 and
the client application 208 only receives and forwards
individual commands, for example, processing rights of the
user are useful only for the server application 205. In this
7928180_1.doc
case, the right to be able to download documents may be an
option for the client application 208.
The rights application 206 runs inside the environment 204,
for example together with the server application 205, on a
computer. The rights application 206 implements the rights
according to the specifications in the rights policy in the
environment 204. These may be specifications of the user or
the server itself. The rights application 206 is preferably
protected from attacks; in particular, mechanisms which
allow keys to be stored by the rights application 206 with a
high degree of security are provided. For example, the
environment 204 comprising the server application 205 and
the rights application 206 can be classified as trusted and
measures which justify such a trusted classification can be
taken or agreed for this environment 204.
The rights application 209 is situated inside the
environment 203, for example on a device belonging to the
user, and implements the user rights specified for the
client side there. The rights application 209 is preferably
protected from attacks (like the rights application 206) and
has mechanisms which can securely store keys.
The server application 205 communicates with the client
application 208, the server application 205 communicating
with the rights application 206 and the client application
208 communicating with the rights application 209 in order
to encrypt a document, determine the rights policy, request
the decryption of the document and implement the specified
rights. For this purpose, the server application 205 and the
client application 208 should be designed to be trusted.
This can be achieved by virtue of the server application 205
and the client application 208 and their actions
respectively being signed, that is to say a signature which
is checked by the rights application 206 and by the rights
application 209 is created.
7928180_1.doc
The rights server 210 is preferably set up to manage the
rights policy (or files which comprise the rights policy)
and the encryption keys of protected documents. The rights
server 210 also communicates with the rights application 209
and the rights application 206. In particular, the rights
server 210 is designed for two clients, that is to say the
two rights applications 209 and 206 in the example.
The approach proposed here is based on an EDRM system or
extends an EDRM system and ensures effective protection from
unauthorized access to documents. For this purpose, a user
is preferably authenticated with a web application, in which
case a sufficiently high degree of security of passwords can
be achieved by means of a particular complexity of the
passwords and a limited allowed period of use. Furthermore,
there may be a requirement for the user to have to input a
password again after an application (session) has expired.
Other or additional authentication mechanisms may also be
provided, for example using biometric methods. Furthermore,
access to particular documents may be enabled with varying
degrees of authentication; for example, access to particular
documents could be allowed only with additional
authentication using a smartcard.
The information required for authentication is preferably
known to the rights server 210 and can advantageously be
uniquely assigned to the correct user. This can be achieved,
for example, by coupling identity management of the cloud
application to identity management of the company which owns
the documents.
It should also be ensured that communication between the
rights server 210 and the two rights applications 209 and
206 is secure; this can be achieved using suitable known
cryptographic functionalities.
Creation of a new document is described by way of example
below:
7928180_1.doc
(1) A user is authenticated with the client application 208
and states his identity and authentication information
in the process. The client application 208 is
authenticated with the server application 205 using the
identity and authentication information.
(2) The user creates a document using the client
application 208 and the server application 205.
(3) The user, as the owner or author of the document,
specifies a rights policy for the document, for example
with the aid of a graphical user interface of the
client application 208 (or alternatively with the aid
of or at least the involvement of the server
application 205).
(4) The user specifies that the document is intended to be
protected according to the rights policy defined by
him. Depending on the architecture of the application,
the document is encrypted using the rights application
209 or the rights application 206.
(5) The rights policy is transmitted, together with the
encryption key, to the rights server 210. A log entry
containing, for example, at least the following entries
is generated: author (username), reference to the
document, reference to the rights policy, date and
time.
An existing document can be accessed, for example, as
described below:
(1) A user is authenticated with the client application 208
and states his identity and authentication information
in the process. The client application 208 is
authenticated with the server application 205 using the
identity and authentication information.
7928180_1.doc
(2) The user wishes to access a particular document (for
example open it) using the client application 208 or
the server application 205. For this purpose, the
application 208 and/or 205 loads the document from the
data memory 207.
(3) Depending on the architecture of the application, the
document can be handled by the rights application 206
or by the rights application 209:
Variant 1: handling by the rights application 206 (on
the server side):
(a) The rights application 206 contacts the rights
server 210 by stating the user and the document.
(b) If the stated user has the required authorization
for the document according to the rights policy,
the rights application 206 receives a rights
object containing the rights policy and the
decryption key for the document from the rights
server 210. The rights server 210 generates a log
entry containing at least the following details:
access (user, document, rights policy, date and
time).
(c) The rights application 206 decrypts the document
and forwards it to the server application 205. In
the event of an action by the user, the server
application 205 first of all asks the rights
application 206 whether this action is allowed
according to the rights policy.
Variant 2: handling by the rights application 209 (on
the client side):
7928180_1.doc
(a) The rights application 209 contacts the rights
server 210 by stating the user and the document
and a reference to the client application 208
used.
(b) If the user has the required rights for the
document according to the rights policy, the
rights application 209 receives a rights object
containing the rights policy and the decryption
key for the document from the rights server 210.
The rights server 210 generates a log entry
containing at least the following details: access
(user, document, rights policy, date and time).
(c) The rights application 209 decrypts the document
and forwards it to the client application 208. In
the event of an action by the user, the client
application 208 first of all asks the rights
application 209 whether this action is allowed
according to the rights policy.
The present solution allows finely graduated access control
to data or applications provided by a cloud, in particular
for document-based applications. In this case, it is
possible for access to be effected under the supervision of
an owner of the data or applications.
One advantage is that the rights policy for a document can
be used to distinguish between rights of a user and rights
of the server. Online processing by the user is therefore
possible without having to grant rights to the server for
this. Online processing by the user presupposes
authentication of the user and is also logged with reference
to the user (for example on the rights server).
Furthermore, it is possible to use the rights policy to also
grant particular rights to the server, with the result that
the latter can automatically carry out predefined tasks, for
7928180_1.doc
example indexing of files. These rights can be reduced to
minimum requirements by not allowing access to the entire
document but rather limiting access only to a section of the
document, for example. This minimizes the possibility for
misuse by administrators of the cloud application or by
other external attackers.
It is also possible to distinguish between the rights of a
user on the local computer on which the client application
runs and on the server on which the server application runs.
These rights are accordingly implemented by rights
applications on the client and the server.
It is therefore advantageous that the owner of the data can
control the use of his data also on external computer
systems. Documents which are processed by cloud applications
can thus be controlled. Such control is achieved, in
particular, by the following properties:
- The document is accessed (decrypted) by the server
application only when an authenticated user who is
authorized according to the rights policy accesses
the document or when a server carries out tasks
which have been explicitly allocated to said server
by the rights policy and have been allowed. Every
access operation can be accordingly logged on the
rights server; in particular, the identity of the
user or the server is stored in a log entry.
- The rights applications of the server and of the
client protect the decryption key received and ward
off attacks by system administrators or other users.
- During transport and data management, the document
is suitably protected by means of encryption and the
decryption key is known only to that application
which is under the control of the owner of the
document.
The correct authentication of users is an important
prerequisite for secure access control. Control of
7928180_1.doc
authentication preferably lies with the respective
application. In particular, authentication can be carried
out using the rights server. If the owner operates the
rights server, control of authentication is under his
control, just like the access rights.
Variant 1:
For authentication with the server application 205, the user
uses a cryptographic authentication token which has been
issued by the user’s company or by a service provider, for
example. If the user wishes to access a protected document,
the server application 205 transfers this authentication
token to the rights server 210 which checks the
authentication token.
This has the advantage that the server application 205 in
the cloud 202 need not be trusted to the effect that
authentication is correctly implemented. Rather, the issuer
of the authentication token (the company or the service
provider here) is trusted. The decision regarding who should
be trusted lies with the operator of the rights server.
Variant 2:
Authentication is requested by the rights server 210:
(1) A user is authenticated with the server application 205
using the client application 208 and, in addition to
his identity and authentication information, states a
reference to his rights application 209 in the process.
(2) If the user wishes to access a protected document via
the server application 205, the following steps are
carried out:
(a) The server application 205 contacts the rights
server 210 by stating the user, the document and
7928180_1.doc
the reference to the user’s rights application
209.
(b) The rights server 210 contacts the rights
application 209 with the request to authenticate
the user. The rights server 210 checks the
authentication, for example by means of coupling
to identity management of the company.
(3) If the user wishes to access a protected document using
the client application 208, the following steps are
carried out:
(a) The user’s local rights application 209 contacts
the rights server 210.
(b) The rights server 210 responds with the request
for authentication to the user. This
authentication is checked by the rights server
210.
Database-based application
It is also possible to provide and/or operate database-based
applications in the cloud. A high degree of security and
control over the data is also intended to be achieved for
such applications.
An EDRM rights language for databases is preferably used for
this purpose and can be used to specify access rights to
data in a database in the form of a rights policy. For this
purpose, the EDRM rights language can provide corresponding
language constructs which can be used to describe which data
(for example objects, tuples, attributes) a user or a
computer (belonging to the user or a server) has access to.
Such a language construct can also be referred to as an RL
expression.
7928180_1.doc
Examples: a user can access a credit card number attribute
of all tuples or the user can access only the credit card
number attribute of the tuples assigned to him.
The rights policy can contain the users with their
respective access authorization and can specify, for each
user, which database entries said user can access. In this
case, different rights can be agreed for different actions,
for example for viewing a database entry or for changing the
database entry. Instead of the user, a computer belonging to
the user can also be identified and authenticated.
A server can also gain access rights which are required, for
example, for automatically running processes, for example
for a keyword search in patient files without accessing the
name or address of the respective patient.
The rights policy can therefore be written down as follows,
for example:
Database:
→ User 1:
RL expression 1 – action(s) - validity range
RL expression 2 – action(s) - validity range
→ User 2:
RL expression 3 – action(s) - validity range
RL expression 4 – action(s) - validity range
→ Server:
RL expression N – action(s) - validity range
RL expression N+1 – action(s) - validity range
In this case, the term “action(s)” stands for a set of
rights which are assigned to a user or a computer belonging
to the user or to a server. For example, rights for
- viewing,
7928180_1.doc
- editing,
- deleting,
- adding,
- etc.
data (records) can be agreed (on the basis of the user,
computer and/or time). Further database-specific actions can
also be assigned rights, for example the right to track
foreign key relationships.
Fig. 3 shows a schematic overview of components of an
architecture for accessing a database 302 stored in a cloud
301.
An environment 307 corresponds, for example, to a company
environment, for example a computer network belonging to a
company. The cloud 301 denotes an environment of an external
network, for example part of the Internet or a network which
is connected to the environment 307 via the Internet. For
example, the cloud 301 is provided by an external service
provider and makes it possible to flexibly access the data
or programs stored in the cloud, in particular the database
302.
The cloud 301 contains an environment 303 which corresponds
to an application environment provided by a service
provider. The environment 303 comprises a database
application 305 and a rights application 306.
An environment 308 which corresponds to an individual
environment of a user is provided inside the environment
307. This may be, for example, a computer which belongs to
the user and is incorporated inside the environment 307. A
client application 309 is provided in the environment 308. A
rights server 304 is also situated inside the environment
307.
The user can use the client application 309 to access the
database application 305 of the cloud 301.
7928180_1.doc
The rights application 306 implements the rights specified
in the rights policy for accessing the database 302 for
users and servers. The rights application 306 and the
database application 305 may run on a common computer and,
in particular, may be accommodated in the same (secure)
environment. The rights application 306 is preferably
suitably protected from attacks and is set up such that keys
can be stored securely.
By means of a database management system, the database 302
comprises a functionality of encrypting data records or
parts of data records (for example attributes or tuples) and
provides the rights application 306 with an interface which
can be used to request decryption of data from the database.
Furthermore, the database 302 implements rights according to
the rights policy, that is to say does not allow data to be
edited, for example, if the corresponding user does not have
a right to do so. For this purpose, the database management
system is designed to be trusted. For example, the database
management system and actions of the latter may be
respectively provided with a signature and the signature can
be accordingly checked by the rights application 306.
The rights server 304 manages the (files of the) rights
policy and the encryption keys of protected data and
communicates with the rights application 306.
It is expressly pointed out again that the user may be an
actual user or a user group with access rights. The user may
also be a computer (belonging to a user) which may have a
corresponding identification. Like a computer or a user, the
server may also have or be provided with particular
predefinable access rights.
The generation of protected data may be described as
follows:
7928180_1.doc
(1) The user is authenticated with the database application
305 using the client application 309, for example a web
application running in a web browser.
(2) The user specifies, for example via a graphical user
interface of the client application 309, a rights
policy which describes the access rights of different
users or of the server to different data (attributes,
objects and/or tuples) in the database 302. The rights
policy relates, for example, to at least one database
302 in the cloud 301, with the result that the rights
policy may comprise a reference to this database 302.
The rights policy is stored on the rights server 304.
(3) The user uses the client application 309 and the
database application 305 to add data to the database
302 and specifies that said data should be protected
according to the rights policy. The rights application
306 encrypts the data with reference to the rights
policy.
(4) The rights policy is sent, together with the encryption
key, to the rights server 304. A log entry containing
at least the following entries is generated: generation
of the data, author (username), reference to the data,
reference to the rights policy, date and time.
The access to and use of protected data can be described as
follows:
(1) A user is authenticated with the database application
305 using the client application 309.
(2) The user calls a function of the database application
305 using the client application 309. The database
application 305 generates a corresponding database call
(for example an SQL query) comprising the identity of
7928180_1.doc
the querying user in order to accordingly check the
rights.
(3) If the database query is aimed at protected entries or
comprises such entries, the database 302 generates
(using its database management system) a request to the
rights application 306 for decryption.
(4) The rights application 306 checks, by asking the rights
server 304, whether the user has the corresponding
access authorization according to the rights policy
and, if this is the case, returns the unencrypted data.
(5) If a function call results in changes to database
calls, the database 302 likewise generates (using its
database management system) a request to the rights
application 306 in order to determine whether the
corresponding user has editing rights for the entry.
Every (attempted) access to a (protected) database entry can
preferably be logged on the rights server 304.
As explained above, it should be ensured that the
authentication of the user is sufficiently secure and is
possibly provided with different security levels for data
with different relevance to security. For example, renewed
authentication may be required after a database session has
expired or after a predefined period of time has elapsed.
In particular, it must be ensured that the rights server 304
can securely communicate with the rights application 306.
Communication between the server application 305 and the
database 302 should likewise be secure. Communication
between the client application 309 and the server
application 305 should likewise be effected in a secure
manner. Suitable known cryptographic methods can be used for
secure communication.
7928180_1.doc
The access protection proposed here for database-based
applications makes it possible for companies to enforce
continuous access control for data from their area of
responsibility even if the data themselves are stored in
databases in the cloud and are used or managed by
applications in the cloud. Access control can be specified
in an accurate and detailed manner, for example on the basis
of or taking into account
- attributes, tuples and/or objects in the database,
- access-authorized persons or groups,
- granted rights, and/or
- a validity period.
One option is to separately allocate rights for the database
application 305 and the client application 309. This makes
it possible to deliberately influence whether protected
data, for example, can already be decrypted by the server
application 305 by means of the database 302 by order of the
user or whether this decryption can take place only in the
environment 308, for example by the client application 309
which, for this purpose, communicates with an additional
rights application in the environment 308 (see, in this
respect, fig. 2 with associated explanation). In this case,
this additional rights application provides a functionality
corresponding to the functionality of the rights application
306 in the environment 308 (for example the user’s local
computer).
For example, a credit card number of the user can be
decrypted only locally on his computer; although the
decryption of the credit card number would be protected by
the rights application 308 in the environment 303, hackers
could attempt to gain access to the data already in the
environment 303 during decryption. However, depending on the
attack scenario, it could be considered to be more secure to
carry out the decryption only locally with the user in the
environment 308.
7928180_1.doc
It is therefore proposed, in particular, to extend known
digital rights management (EDRM: Enterprise Digital Rights
Management) such that control over access to data stored in
a cloud remains with the user or creator of the data. For
this purpose, coordination of the access information between
a rights application in the cloud and a rights server in the
area of the user (that is to say outside the cloud) is
advantageous. A rights policy makes it possible to control
access for users (user groups), computers (client, server)
and validity periods in a fine-grained manner. In this case,
access comprises a wide variety of actions which can be
carried out with the data. In particular, it is advantageous
that a server application gains (temporally limited) access
to some of the data in order to index the latter, for
example, without the server being able to access the
complete contents of the data in this case. The approach
works, for example, for document management and for
databases outsourced to the cloud. The invention can be used
for any type of distributed data processing in which the
data are intended to be protected from unauthorized access.
Although the invention has been described and illustrated in
more detail using the at least one exemplary embodiment
shown, the invention is not restricted thereto and other
variations can be derived therefrom by a person skilled in
the art without departing from the scope of protection of
the invention.
The term “comprising” as used in this specification and
claims means “consisting at least in part of”. When
interpreting statements in this specification and claims
which include “comprising”, other features besides the
features prefaced by this term in each statement can also be
present. Related terms such as “comprise” and “comprised”
are to be interpreted in a similar manner.
7928180_1.doc
Claims (31)
1. A method for accessing data stored in a cloud, with - a provider of the cloud; - an entity which accesses the data, the entity comprising at least one of: - a client application, - a server application, - a user wishing to access the data using the client and/or server application; - at least one rights application; - a rights server which is not subject to the control of the cloud provider and comprises a rights policy which can be used to define at least the following access rights: ▪ access rights of users and/or user groups, ▪ access rights of client and/or server applications, having the following steps: (a) the rights application is inquired whether access to the data by the accessing entity is allowed; (b) the rights application informs the rights server of the requested access; (c) the rights server provides an item of access information which can be used to determine whether access is allowed according to the access rights of the accessing entity; (d) the data can be accessed only when access is allowed according to the access information.
2. The method as claimed in claim 1, in which, before step (a), a client application is authenticated with a server application.
3. The method as claimed in any one of the preceding claims, in which the rights application accesses the data and forwards the data to the server application. 7928180_1.doc
4. The method as claimed in any one of the preceding claims, in which the client application transfers an authentication token to the server application, which token is transmitted from the rights application to the rights server in order to gain access to the data.
5. The method as claimed in any one of the preceding claims, in which the client application transfers a reference which is transmitted from the rights application of the server to the rights server, the rights server requesting and/or carrying out authentication on the basis of the reference.
6. The method as claimed in the preceding claim, in which the reference is a reference to a rights application of the client.
7. The method as claimed in any one of the preceding claims, in which the inquiry from the rights application comprises at least one of the following items of information: - an item of user information, - an item of computer information, in particular an identification of a computer, - an item of information for identifying the data which are intended to be accessed.
8. The method as claimed in any one of the preceding claims, in which the access information comprises: - a rights policy; - a key for decrypting the data.
9. The method as claimed in any one of the preceding claims, in which the rights server checks, on the basis of the inquiry from the rights application, whether access to the data is allowed by carrying out a comparison with the rights policy previously created for the data. 7928180_1.doc
10. The method as claimed in any one of the preceding claims, in which the rights policy comprises at least one of the following items of information: - an item of user or computer information, - an action which can be carried out by the user or computer, - an action which cannot be carried out by the user or computer, - a validity period.
11. The method as claimed in any one of the preceding claims, in which communication between the rights server and the rights application is secure.
12. The method as claimed in any one of the preceding claims, in which the rights server logs at least one inquiry.
13. The method as claimed in any one of the preceding claims, in which the data are in the form of: - at least one document, - at least one application, - at least one database, - at least one data record in a database, or - at least one database entry.
14. The method as claimed in any one of the preceding claims, in which access is allowed according to the access rights when the access information is provided by the rights server.
15. The method as claimed in any one of the preceding claims, in which the access information comprises the access rights of the entity wishing to access the data.
16. The method as claimed in any one of the preceding claims, in which the access information comprises a 7928180_1.doc reference to an application which can be used to check the access rights.
17. The method as claimed in the preceding claim, in which access is enabled according to the access information when access is allowed by the referenced application upon request.
18. The method as claimed in any one of the preceding claims, in which the access rights are limited to part of the data.
19. The method as claimed in the preceding claim, in which the part is in the form of a keyword part of a document or an attribute, tuple and/or object in a database.
20. The method as claimed in any one of the preceding claims, in which the access rights have a time limit.
21. The method as claimed in any one the preceding claims, in which the data are stored in encrypted form and the access information is required to decrypt said data.
22. The method as claimed in any one of the preceding claims, in which data stored in encrypted form are decrypted by the rights application.
23. The method as claimed in any one of the preceding claims, in which the rights application is part of the client application or the server application.
24. The method as claimed in any one of the preceding claims, in which at least two rights applications are provided, one of which is assigned to the client application and one of which is assigned to the server application.
25. The method as claimed in any one of the preceding claims, in which the server application and its assigned 7928180_1.doc rights application are arranged in an environment controlled by the cloud provider.
26. The method as claimed in any one of the preceding claims, in which the rights server is controlled by the entity which stores the data in the cloud.
27. The method as claimed in any one of the preceding claims, in which the access rights of the client application and of the server application differ from one another.
28. A system for accessing data stored in a cloud, the system comprising at least one of: - a provider of the cloud; - an entity which accesses the data, the entity comprising at least one of: - a client application, - a server application, - a user wishing to access the data using the client and/or server application; - at least one rights application; - a rights server which is not subject to the control of the cloud provider and comprises a rights policy which can be used to define at least the following access rights: ▪ access rights of users and/or user groups, ▪ access rights of client and/or server applications; the system configured to carry out the method of any one of the preceding claims.
29. A cloud infrastructure configured to carry out the method of any one of claims 1 to 27, which is designed in such a manner that the data can be accessed only when access is allowed according to the access information.
30. A rights server configured to carry out the method of any one of claims 1 to 27, which is not subject to the control of the cloud provider, comprising a rights policy 7928180_1.doc which can be used to define at least the following access rights: ▪ access rights of users, ▪ access rights of client and/or server applications.
31. A method for accessing data stored in a cloud, with - a provider of the cloud; - an entity which accesses the data, the entity comprising at least one of: - a client application, - a server application, - a user wishing to access the data using the client and/or server application; - at least one rights application; - a rights server which is not subject to the control of the cloud provider and comprises a rights policy which can be used to define at least the following access rights: ▪ access rights of users and/or user groups, ▪ access rights of client and/or server applications, the method substantially as herein described with reference to any embodiment shown in
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE102011077218.9 | 2011-06-08 | ||
DE102011077218.9A DE102011077218B4 (en) | 2011-06-08 | 2011-06-08 | Access to data stored in a cloud |
PCT/EP2012/058514 WO2012168019A2 (en) | 2011-06-08 | 2012-05-09 | Access to data stored in a cloud |
Publications (2)
Publication Number | Publication Date |
---|---|
NZ618683A NZ618683A (en) | 2016-01-29 |
NZ618683B2 true NZ618683B2 (en) | 2016-05-03 |
Family
ID=
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11290446B2 (en) | Access to data stored in a cloud | |
US10554635B2 (en) | Protecting documents using policies and encryption | |
US9946895B1 (en) | Data obfuscation | |
US9213867B2 (en) | Secure cloud database platform with encrypted database queries | |
CA2709944C (en) | System and method for securing data | |
US8850593B2 (en) | Data management using a virtual machine-data image | |
US20130159732A1 (en) | Password-less security and protection of online digital assets | |
US20120324225A1 (en) | Certificate-based mutual authentication for data security | |
US9152813B2 (en) | Transparent real-time access to encrypted non-relational data | |
KR20060096887A (en) | Method and computer-readable medium for generating usage rights for an item based upon access rights | |
CN112825520A (en) | User privacy data processing method, device, system and storage medium | |
Behera et al. | Big data security threats and prevention measures in cloud and Hadoop | |
Jensen et al. | Assigning and enforcing security policies on handheld devices | |
CN114253660A (en) | System and method for authorizing a user data processor to access a container of user data | |
Solsol et al. | Security mechanisms in NoSQL dbms’s: A technical review | |
Ko et al. | A study on secure medical-contents strategies with DRM based on cloud computing | |
NZ618683B2 (en) | Access control to data stored in a cloud | |
US20220092193A1 (en) | Encrypted file control | |
Haunts et al. | Key Storage and Azure Key Vault | |
Kiyomoto et al. | LMM: A common component for software license management on cloud | |
Beley et al. | A Management of Keys of Data Sheet in Data Warehouse | |
Han | Confidential Documents Sharing Model Based on Blockchain Environment | |
WO2024030308A1 (en) | Data exchange protection and governance system | |
Browning | Security Features in the Teradata Database |