Information Technology Reference
In-Depth Information
(e.g., a CRB) in different domains before it is
scheduled at some host. Each of these hosts or
domains may be malicious, and the administrator
or an attacker that gains access to one of these
hosts may replace the original job with another
program that leaks information to an external
party. Alternative authentication schemes (e.g.,
username/password-based) do not improve this
situation.
For this paper, we assume that the implemen-
tation of a job is trusted when this job's owner
is trusted. In particular, we assume that medical
researchers are aware of confidentiality aspects
regarding medical data and treat this data as con-
fidential information - and as a result use only
trusted programs to make use of this data. In the
proposed framework, jobs can only access data
from hosts that are trusted by the data owner, and
we assume that a job submitted by a trusted user
will not leak information to unauthorized parties.
A mechanism is presented later in this paper that
allow users to seal jobs in such a way that tamper-
ing with these jobs is not possible.
Note that mechanisms exist that limit the
capabilities of a possibly untrusted program to
export information to arbitrary external parties,
e.g., using the jailing system described in (van 't
Noordende, Balogh, Hofman, Brazier, and Tanen-
baum, 2007). Such solutions can be considered
as additional measures to increase security, but
are outside the scope of this paper.
For this paper, we assume that jobs do not ship
potentially privacy-sensitive (output) data back
to the possibly untrusted CRB through which
the they entered the system. Instead, jobs should
be programmed to encrypt output data with the
job owner's public key before returning to their
CRB, or they should store any potentially sensitive
(output) data only on secure storage, preferably
the system that contained the input data.
Summarizing, a number of implementation
issues should be solved before we can be sure
that privacy-sensitive information cannot be ac-
cessed by unauthorized parties. First, a secure
binding between jobs and Proxy certificates
must be provided. Second, a data owner should
be able to express in a policy which administra-
tive domains he or she trusts to handle privacy
sensitive information in a safe way, based on a
risk assessment. Third, a data owner should be
able to express policies with regard to a remote
system's configuration details which are relevant
to privacy and security and the way in which data
is handled.
THE TSRB FRAMEWORK
We propose a framework for secure handling of
privacy sensitive information on Grids that al-
lows for controlling data access and distribution
aspects. The components and interactions of the
framework are presented in Figure 2.
The framework is centered around a secure
storage infrastructure called Trusted Storage
Resource Broker (TSRB). There may be many
TSRBs on the Grid, possibly managed by differ-
ent administrative domains in different VOs. The
TSRB is coined ``trusted'', because (1) it is de-
ployed in an administrative domain trusted by the
data owner, and (2) it is trusted to enforce data-
owner specified access control policies. The TSRB
controls access to data items or collections by
combining User-based Access Control Lists (User
ACLs) and Host-ACLs. Host ACLs contain re-
quired host properties that must be met by a remote
host before the data can be accessed by a job on
this host.
Required host properties are described by
the data owner in a Remote Host Property List
(RHPL). Each host has a Host Property List
(HPL) that contains host configuration details.
The HPL contents are matched with the data's
RHPL at connection time. The HPL is maintained
by the remote host (Cluster A in Figure 2), and is
signed by the host's administrator. The TSRB also
maintains for each data collection or item a Host
ACL containing a list of administrative domains
Search WWH ::
Custom Search