[ogsa-d-wg] Security issues for data services

[Allen Luniewski]

I have a few comments to offer to the note that Dave sent and the thread 
that has ensued.   I hope that these are helpful.

Allen


owner-ogsa-d-wg at ggf.org wrote on 06/03/2005 10:20:12 AM:

> All,
> 
> At the London meeting we agreed to discuss security issues at next 
> Wednesday's telcon, and to mail round thoughts in advance.  Many of 
> you know far more than I, but I thought I'd send round some naïve 
> thoughts to kick off the discussion.  Please correct and develop 
> these comments.
> 
> Dave.
> 
> 
> Access to data elements requires authorisation, possibly at the 
> level of each individual element.  Depending on the data model, this
> level may be finer-grain than the level of the resource.  E.g. if 
> the resource is a file system, the access control will be at the 
> level of individual files.  Furthermore, in a database system, the 
> access control will be at the level of individual tables and/or 
> attributes; as such the access may depend on the content of a 
> particular query.

Actually some DBs provide access control down to the level of cells in
tables.  Also, we need to keep in mind that there are two distinct
security models that must be taken into account: discretionary controls
and nondiscretionary controls.

If we are providing what amounts to a grid facade over a primary data 
source,
it is hard for me to justify a model where that underlying security 
constraints
are not enforced.  it is okay, I think, that the grid oriented interface
provide more restrictive access.

> 
> Some types of data have strict privacy policies that restrict the 
> queries that are allowed.  These restrictions may apply to sets of 
> queries, so whether a query is permitted may depend on previous 
> queries coming from the same user.

Quite true.  And very challenging from a technology point of view.
> 
> Replication services need to enforce common security levels for the 
> replicas.  This may require replicating the security metadata.

I basically agree with this.  But this is not as simple as one might hope.
I take this view since a replica is something whose properties 
(integrity?)
are "guaranteed by the replication service.

A copy, as discussed by Bill, is a point in time copying of data - outside 
of
possibly being involved in capturing the data for the user, replication 
has
nothing to do with the copy. If there are security concerns with the copy, 
and
there frequently are, then there are mechanisms outside the IT environment
(e.g., prison terms) that enforce the security rules.

Now back to my initial comment that this is complicated.  Consider the 
following:
        1. Who owns the replicated data?  Is it the replication service or 
some user?
                Is it an administrator?
        2. How can the replication service prevent an administrator of the 
target system
                from changing the access controls on the replica?
        3. If the source allows updates, must replication allow updates at 
the replica?
                This could be challenging to the replication service.
        4. Is it sensible for a replica to allow updates that are not 
propagated back
                to the source?

> 
> Federation services need to access data in the federated resources. 
> This presumably requires some federation of the security model.

A couple of things to think about:
        1. Are authentication credentials passed from the application 
through the
                federating server to the backend sources?  Or does the 
federating server
                use its own authentication?
        2. In either case, I think that the federating server is obligated 
to honor the
                access controls of the sources.
        3. Can the federating server provide a more restrictive set of 
access controls
                than the sources?
        4. There is an issue in here about privacy concerns and how they 
interact with
                the federating server.  But I have not thought these 
though enough to
                articulate them well.
        5. Bill's concerns about multiple authentication and access checks 
when accessing
                a federated source are well taken.  The architecture 
should allow (encourage?)
                mechanisms that minimize this overhead.
        6. We clearly need a clean way to answer the question "why could I 
not access that
                data?"
        7. There are a whole slew of questions arising around aggregation 
of data and
                hiding of personal data that federation is not going to 
make any easier.

> 
> Users may want to restrict other people from seeing which queries or
> commands they are sending.  This may affect the logging 
> functionality of the service as well as the security of the 
> transmission channel.

This is probably correct - privacy concerns and laws.

> 
> Users with confidential data want assurance that their data will not
> be read by other users or administrations of a server.  They want 

Is this anything more than saying that the data infrastructure must 
support
security?

> assurance that the services or executables invoked on the data are 
> the actual services or executables expected (as opposed to trojans, 
etc).

Again, is this anything more than saying that authentication must be part 
of
the basic infrastructure?
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-d-wg/attachments/20050606/645cd666/attachment.htm