On Mon, Mar 17, 2014 at 04:03:28PM -0500, Shazia Sathar wrote: > The DSpace instance I am working on will be used to facilitate data sharing > of very sensitive information, for example, identifiable health-related > information. Hence, there is a need to make it a very secure application. I > am in the process of obtaining information on what needs to be done in > order to make it secure- server configurations, application configuration, > database security, etc.
You will want everyone behind a good firewall, then. Most of the work on DSpace is done with open access in mind. Reasonable attention is paid to access control, but I don't think this has ever been thoroughly audited. To be honest, if it were my project I would not use DSpace for highly sensitive information just yet. (I don't know what I *would* recommend.) A possible work-around would be to store only assets which are already encrypted. If the metadata are not themselves sensitive information then this might be workable. > Currently, I have setup the application on one server and the database on > another. Upon reading the dspace documentation, however, I figured that the > assetstore directory contains the uploaded data. > > 1. Any ideas on how I can secure this directory? Is it possible to > retrieve the item if the directory gets compromised or does the database > have some key which is required to retrieve the item? Assets are not encrypted by DSpace. They are scattered through a moderately deep tree of subdirectories, by means of a well-known hashing function of their content. The database holds the relationship. So it's difficult to find a specific asset without using the product, but not difficult at all to read or copy anything you find. Your only real defense here is to prevent shell access by untrusted people. (And, as usual, physical access means Game Over.) > 2. Does it make more sense to move the assetstore directory to a secure > location? If yes, how can I go about doing this? Since the database will > have login credentials for all registered users, and the fact that > registered users have access to the protected information, should I > consider keeping the assetstore directory and database separated from where > the application resides? If you are going that detailed, we need to know your threat model. > 3. Any configuration settings on Apache httpd and tomcat other than making > dspace run on https? Make sure that HTTPD does not itself give anyone access to the assetstore. Likewise Tomcat. > 4. How can I perform an audit on the system? For example, get a list of > users who downloaded a particular item. All access is logged to [DSpace]/log/dspace.log* . There are a lot of other records in there too, but the code contains examples of dredging specific kinds of information out of the log. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient.
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech
_______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
