REDDnet LStore Security Overview: Difference between revisions
No edit summary |
No edit summary |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 8: | Line 8: | ||
!style="background:#000000;color:#ff8888"|Role | !style="background:#000000;color:#ff8888"|Role | ||
!style="background:#000000;color:#ff8888"|Name | !style="background:#000000;color:#ff8888"|Name | ||
!style="background:#000000;color:#ff8888"|Phone | !style="background:#000000;color:#ff8888"|Phone | ||
|- | |- | ||
|Primary | |Primary | ||
|Mathew Binkley | |Mathew Binkley | ||
|Phone: (615) 322-5857 | |Phone: (615) 322-5857 | ||
|- | |- | ||
|Secondary | |Secondary | ||
|Alan Tackett | |Alan Tackett | ||
|Phone: (615) 322-1028 | |Phone: (615) 322-1028 | ||
|} | |} | ||
==Data | ==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. | 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 | Cursory work on an OpenSSL-encrypted upload/download has been done, but is not yet ready for public use. | ||
==Data Integrity== | ==Data Integrity== | ||
When the client uploads a file to the depots, it | When the client uploads a file to the depots, it can optionally compute a MD5 hash of the file and store 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 | ==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. | 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. | ||
| Line 42: | Line 39: | ||
==Access Permissions== | ==Access Permissions== | ||
We | We are implementing a generic policy framework that allows for custom security policies (role-based, Unix ACL and permissions) based on user requirements. | ||
Latest revision as of 15:28, 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 | Phone |
|---|---|---|
| Primary | Mathew Binkley | Phone: (615) 322-5857 |
| Secondary | Alan Tackett | 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 can optionally compute a MD5 hash of the file and store 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 are implementing a generic policy framework that allows for custom security policies (role-based, Unix ACL and permissions) based on user requirements.