REDDnet LStore Security Overview - Revision history

Wikiadmin at 21:28, 30 March 2010

2010-03-30T21:28:57Z

← Older revision		Revision as of 16:28, 30 March 2010
Line 27:		Line 27:
	==Data Integrity==		==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).		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.		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.

Wikiadmin at 21:27, 30 March 2010

2010-03-30T21:27:43Z

← Older revision		Revision as of 16:27, 30 March 2010
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"\|Email~~
	!style="background:#000000;color:#ff8888"\|Phone		!style="background:#000000;color:#ff8888"\|Phone
	\|-		\|-
	\|Primary		\|Primary
	\|Mathew Binkley		\|Mathew Binkley
	~~\|Mathew.Binkley@vanderbilt.edu~~
	\|Phone: (615) 322-5857		\|Phone: (615) 322-5857
	\|-		\|-
	\|Secondary		\|Secondary
	\|Alan Tackett		\|Alan Tackett
	~~\|Alan.Tackett@accre.vanderbilt.edu~~
	\|Phone: (615) 322-1028		\|Phone: (615) 322-1028
	\|}		\|}

Wikiadmin at 21:13, 30 March 2010

2010-03-30T21:13:01Z

← Older revision		Revision as of 16:13, 30 March 2010
Line 42:		Line 42:
	==Access Permissions==		==Access Permissions==

	We ~~implement~~ a generic policy framework that allows for custom security policies (role-based, Unix ACL and permissions).		We are implementing a generic policy framework that allows for custom security policies (role-based, Unix ACL and permissions) based on user requirements.

Wikiadmin at 21:12, 30 March 2010

2010-03-30T21:12:36Z

← Older revision		Revision as of 16:12, 30 March 2010
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==

Wikiadmin at 21:04, 30 March 2010

2010-03-30T21:04:55Z

← Older revision		Revision as of 16:04, 30 March 2010
Line 22:		Line 22:
	\|}		\|}

	==Data ~~Encryption~~==		==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.
Line 34:		Line 34:
	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 other hashes supported by the base SSL library.

	==Data ~~Redundancy~~==		==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.

Wikiadmin at 21:01, 30 March 2010

2010-03-30T21:01:48Z

← Older revision		Revision as of 16:01, 30 March 2010
Line 33:		Line 33:

	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 other hashes supported by the base SSL library.


	==Data Redundancy==		==Data Redundancy==

Wikiadmin: Created page with '==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. …'

2010-03-30T21:01:37Z

Created page with '==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. …'

New page

==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==

{|
!style="background:#000000;color:#ff8888"|Role
!style="background:#000000;color:#ff8888"|Name
!style="background:#000000;color:#ff8888"|Email
!style="background:#000000;color:#ff8888"|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 Encryption==

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.

==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 other hashes supported by the base SSL library.

==Data Redundancy==

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).