Some cluster users may have data that is classified as sensitive (e.g. data from dbGaP). Extra care should be taken with this data to prevent unauthorized access.

Specific security requirements for your data may vary depending on the source of the data. The cluster does satisfy some of the standard requirements…

• The cluster is housed in a server room with card-controlled access. Accesses to the room are logged.
• The cluster backup machines are housed in server rooms with card-controlled, logged, access.
• The cluster can be accessed only over SSH. No other services are active on the cluster, and no other ports are open to the internet.
• The cluster is kept up to date with operating system security patches.
• The cluster provides encrypted disk volumes for sensitive data that must be stored on an encrypted volume (see below).

The cluster may not conform to some best practices…

• The cluster generally uses Unity Ids and passwords for user accounts. Unity passwords do not have very strong security requirements (e.g. they do not have to be very long).
• The cluster does not expire passwords (although unused accounts are locked after 6 months). Newer best practices do not consider complexity requirements and expiration of passwords to be worthwhile (e.g. 2019 NIST 800-63).
• The cluster does not limit copying of data which you have permission to read.
• The cluster does not yet have 2-factor authentication.

It is your responsibility to ensure that your sensitive data is adequately protected (the system administrators can't determine which data are sensitive): but you can let the administrators know about specific needs and get help with making sure that the data are secure.

One way in which sensitive data can be protected is by only storing it on encrypted disk volumes. Currently, of the cluster disk volumes, only /home1, /home6, and /scratch are encrypted (i.e. all the data is encrypted before being written to disk and decrypted when read). (This is also known as encryption “at rest”.) This encryption protects against the server being stolen, or being improperly disposed of (with the disks and data intact) at some point in the future. The backup volumes to which the data on /home1 and /home6 are copied are also encrypted.

If you have a project that includes the use of sensitive data please talk to the system administrators to see whether you should store that data on /home1, /home6, or have your entire home directory moved to an encrypted volume.

The /scratch volume is not backed up, but is encrypted.

If you have sensitive data you should ensure that your home directory, or the directories containing the sensitive data, or the data files themselves are not world readable.

For example:

chmod o-rwx sensitive_directory

will stop general users of the cluster accessing files in “sensitive_directory”.