Security issues for data services
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. 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. Replication services need to enforce common security levels for the replicas. This may require replicating the security metadata. Federation services need to access data in the federated resources. This presumably requires some federation of the security model. 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. Users with confidential data want assurance that their data will not be read by other users or administrations of a server. They want assurance that the services or executables invoked on the data are the actual services or executables expected (as opposed to trojans, etc).
Dave, Thunderbird didn't seem to like your HTML mail, it wouldnt wrap the HTML and so the lines were veeerrrryyyyy long. Anyway, a couple of comments: I disagree that replication services need to enforce common security levels for replicas. If I have read access to a file, I can copy it and set its access to whatever I want. If that is important data, it is assumed that since I have read access I will take care of it. A community may wish to impose consistent access rights across replicas, but that is a policy issue not something inherent in replication services. As to the federated security model, I again dont think that is necessary, if I access n different sites, I have to do n authentication and authorization checks and if any one of them fails the access fails. This does imply some things about uniform identity, they all trust the same CAs, even that they are all using the same security mechanism. It would also be a major pain to debug access problems, particularly if the system is dynamically choosing the resource so you dont even know where are accessing things. I suppose it might be possible to query your rights across all the resources and present a federated access rights list that was the least common denominator. The idea of users not wanting anyone, including admins knowing what they have stored is a security concern. How do we know that they are not storing stolen top secret information or that they are actually running bomb design software. I dont subscribe to this, but I have heard this argument from security folks before. Bill -- William E. Allcock Argonne National Laboratory Bldg 221, Office C-115A 9700 South Cass Ave Argonne, IL 60439-4844 Office Phone: +1-630-252-7573 Office Fax: +1-630-252-1997 Cell Phone: +1-630-854-2842
Hi, I have a couple of questions on the paragraph below:
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.
In most instances is it not the case that the security model that is to be observed will be predominantly inherited from the underlying data resource. So in a unix file system the grid credentials of the user might be mapped to a user and the access policies for that user would be observed. A similar case would correspond to databases. So, in most instances the security model of the underlying data resource is observed - maybe that should be a basic principle. The problem arises when objects/data is created by the service layer which is then stored in the service layer (or the underlying data resource). How do you associate a security policy with this data? If I derive some data from the data resource and store it in memory accessible through another service how do I bind a security policy with that or if I derive data and want to have a different access policy from the original data (or the default access privileges) - how do I do that? A similar issue arises with metadata which lives at the service layer. Is it the case that in order to access that metadata you must have the same credentials as would be required to access the underlying data resource? Mario +-----------------------------------------------------------------------+ |Mario Antonioletti:EPCC,JCMB,The King's Buildings,Edinburgh EH9 3JZ. | |Tel:0131 650 5141|mario@epcc.ed.ac.uk|http://www.epcc.ed.ac.uk/~mario/ | +-----------------------------------------------------------------------+
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@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?
participants (4)
-
Allen Luniewski
-
Dave Berry
-
Mario Antonioletti
-
William E. Allcock