REDDnet LStore Security Overview: Difference between revisions

From ReddNet
Jump to navigation Jump to search
No edit summary
No edit summary
Line 26: Line 26:
L-Store is currently under development.  At the moment, data is not encrypted in transit or in storage.  If the user desires, they may use common encryption tools such as OpenSSL or GnuPG to encrypt their data before uploading.
L-Store is currently under development.  At the moment, data is not encrypted in transit or in storage.  If the user desires, they may use common encryption tools such as OpenSSL or GnuPG to encrypt their data before uploading.


Cursory work on an OpenSSL-encrypted upload/download has been done, but is not yet ready for public consumption.
Cursory work on an OpenSSL-encrypted upload/download has been done, but is not yet ready for public use.


==Data Integrity==
==Data Integrity==
Line 32: Line 32:
When the client uploads a file to the depots, it computes a MD5 hash of the file and stores that information in the metadata on the server.  Downloaded files can be hashed and compared with the stored value to verify integrity (though this is not yet automated).
When the client uploads a file to the depots, it computes a MD5 hash of the file and stores that information in the metadata on the server.  Downloaded files can be hashed and compared with the stored value to verify integrity (though this is not yet automated).


We intended to make the choice of hash user-selectable in the future.  We intend to support SHA-1, SHA-256, SHA-512 hashes, and other hashes supported by the base SSL library.
We intended to make the choice of hash user-selectable in the future.  We intend to support SHA-1, SHA-256, SHA-512 hashes, and possibly other hashes as supported by the base SSL library.


==Data Reliability==
==Data Reliability==

Revision as of 16:12, 30 March 2010

Security overview

REDDNet's current security plan maintains a level of security that balances security requirements with the service and academic freedom our users expect. We are capable of enforcing stricter security measures than those outlined in this document should a specific need arise.

Security contacts

Role Name Email Phone
Primary Mathew Binkley Mathew.Binkley@vanderbilt.edu Phone: (615) 322-5857
Secondary Alan Tackett Alan.Tackett@accre.vanderbilt.edu Phone: (615) 322-1028

Data Security

L-Store is currently under development. At the moment, data is not encrypted in transit or in storage. If the user desires, they may use common encryption tools such as OpenSSL or GnuPG to encrypt their data before uploading.

Cursory work on an OpenSSL-encrypted upload/download has been done, but is not yet ready for public use.

Data Integrity

When the client uploads a file to the depots, it computes a MD5 hash of the file and stores that information in the metadata on the server. Downloaded files can be hashed and compared with the stored value to verify integrity (though this is not yet automated).

We intended to make the choice of hash user-selectable in the future. We intend to support SHA-1, SHA-256, SHA-512 hashes, and possibly other hashes as supported by the base SSL library.

Data Reliability

Data stored on depots is encoded with RAID 5 redundancy. The user may specify this redundancy across hard drives, across depots, and/or across sites. REDDNet monitors depots for drive failures using Nagios, and if a loss of redundancy is detected we correct the error on our end.

In addition, we are working on a generalized Reed-Solomon code that will allow users to specify an arbitrary amount of redundancy. For example, you could have 10 drives and have 4 of them fail before you lost redundancy. We expect this generalized redundancy code to be completed in summer 2010.

Access Permissions

We implement a generic policy framework that allows for custom security policies (role-based, Unix ACL and permissions).