Secure research data containing HIPAA-regulated PHI on high performance file systems at IU

• Overview
• Encryption
• Access control
  • Create a separate directory for files containing PHI
  • Make sure only you have access
  • About Access Control Lists (ACLs)
  • Use ACLs to share your protected directory with another user
  • Remove a user's permissions
• Get help

Overview

For more, see Your legal responsibilities for protecting data containing protected health information (PHI) when using UITS Research Technologies systems and services.

The information in this document is intended to help IU researchers implement access control methods and technical controls for safeguarding the privacy and security of files containing PHI stored on Slate, Slate-Project, or Slate-Scratch.

Encryption

IU data management standards require that files containing PHI be encrypted at rest. To further enhance security:

• Use GPG to encrypt all files containing PHI. On IU's research supercomputers, you can use GPG to encrypt individual files; for instructions, see Use GPG to encrypt files on IU's research supercomputers. The resulting encrypted files will have the .gpg extension.
• Unencrypt only the files needed as input for your application; other files containing PHI that are not needed for your application should remain encrypted.
• Delete unencrypted files when you no longer need them. You can use cron to help manage unencrypted files, for example, by periodically running a script that checks for any unencrypted files (files without a .gpg extension) that were last accessed more than seven days ago.

• At Indiana University, never store files containing sensitive institutional data, especially protected health information (PHI) regulated by the Health Insurance Portability and Accountability Act of 1996 (HIPAA), on your desktop workstation, laptop, USB flash drive, tablet, smartphone, or other mobile device unless the files are properly encrypted on the device, and your senior executive officer or the IU Institutional Review Board (IRB) has given prior written approval. Because PHI must remain encrypted at rest, make sure you are using full-disk encryption on any device that has research data containing PHI on it. If you are not sure, ask your department or school local UITS support person for help.

Access control

Access to research data containing PHI must be kept under strict control. Store files containing PHI in a separate directory to which only you have access. If you need to share files containing PHI with research collaborators, use Access Control Lists (ACLs) to set file- and directory-level permissions that provide as-needed access to authorized users only.

Create a separate directory for files containing PHI

Log into your account on one IU's research supercomputers, and then use the mkdir command to create a directory named protected in your space on the appropriate file system (replace username with your IU username or my_project with the name of your project):

• Slate:

  mkdir /N/slate/username/protected

• Slate-Project:

  mkdir /N/project/my_project/protected

• Slate-Scratch:

  mkdir /N/scratch/username/protected

Make sure only you have access

The permissions for your protected directory should be set to grant read, write, and execute access to the owner (you) only. No access at all should be granted to group members or other users. To set permissions on your protected directory so only you have access, on the command line, enter the following (replace /path/to/your/protected with the path to your protected directory from above):

chmod 700 /path/to/your/protected

Alternatively, to configure your user environment so that every new file and directory gets the same permission level (accessible only by the owner), add the following line to your shell profile:

umask 077

To check the permissions on your protected directory, on the command line, enter the following (replace /path/to/your/protected with the path to your protected directory from above):

ls -ld /path/to/your/protected

You should see output similar to the following, which shows that only the owner (username) has read, write, and execute access to the specified directory:

drwx------ 2 username group 4096 Apr 30 14:54 /path/to/your/protected

About Access Control Lists (ACLs)

An ACL is a data structure containing entries that specify the access permissions (read, write, and/or execute) on an associated object (file or directory) for an individual user or group of users. To view the ACL for a file or directory, use the getfacl command; for example:

getfacl work_dir

This command produces output similar to the following sample ACL:

# file: work_dir
# owner: username
# group: bio
user::rwx
group::r-x
other::r-x

The sample ACL above shows that the default directory permissions are set for the work_dir directory, which is owned by user username in the owning group bio; the last three lines indicate the following:

Use ACLs to share your protected directory with another user

To share your protected directory with another IU research supercomputer user:

1. Grant the user read and execute permissions to the parent directories above your protected directory. The user needs these permissions to read and change into (cd) all the directories above your protected directory.

   To do this, use the setfacl command with the -m option to modify the existing ACL for your space. For example, to grant user user1234 read and execute permissions to the parent directories above your protected directory, use the appropriate command below (replace username with your IU username or my_project with the name of your project):

   • Slate:

     setfacl -m u:user1234:rx /N/slate/username

   • Slate-Project:

     setfacl -m u:user1234:rx /N/project/my_project

   • Slate-Scratch:

     setfacl -m u:user1234:rx /N/scratch/username

   In the preceding examples:

   • The -m option indicates you are modifying the ACL for the named file or directory.
   • The u:user1234:rx string indicates that the permissions being set are for an individual user (u), and that the user (user1234) is granted read and execute permissions (rx) on the specified directory.
2. Grant the user read and execute permissions to your protected directory. To do this, use the setfacl command with the -m option to modify the existing ACL for your protected directory.

   For example, to grant user user1234 read and execute permissions to your protected directory, use the following command (replace /path/to/your/protected with the path to your protected directory from above):

   setfacl -m u:user1234:rx /path/to/your/protected

   Note:

   • To grant access permissions to multiple users in a single command, use a comma (without spaces) to separate the user entries; for example (replace /path/to/your/protected with the path to your protected directory from above):

     setfacl -m u:user1234:rx,u:user5678:rx /your/path/to/protected

   • To grant access permissions for a user to all pre-existing files and subdirectories located within your protected directory, use the -R (recursive) option; for example (replace /path/to/your/protected with the path to your protected directory from above):

     setfacl -R -m u:user1234:rx /path/to/your/protected

     The above command gives user1234 read and execute permissions to the specified directory, and to any files or subdirectories that are already located within that directory. To make these permissions apply to new files and subdirectories that are created in the future within your protected directory, you must set a default ACL (see the next step).

3. Grant the user read and execute permissions to any new files and/or subdirectories that are created in the future within your protected directory. To do this, use the setfacl command with the -d and -m options to create a default ACL for your protected directory.

   For example, to create a default ACL that automatically grants user user1234 read and execute permissions to any files and subdirectories that are added to your protected directory in the future, use the appropriate command below (replace /path/to/your/protected with the path to your protected directory from above):

   setfacl -d -m u:user1234:rx /path/to/your/protected

   Note:

   • If you don't set the default ACL in this manner, any files and subdirectories created in your protected directory in the future will inherit only the default file mode permissions, and the user sharing your protected directory will not be able to access those new files and directories.
   • Pre-existing files and directories that are copied or moved into a directory with a default ACL set on it do not inherit the default ACL's permissions. Consequently, whenever you copy or move content from another location into your protected directory, you must use the setfacl command with the -R and -m options to reset the ACL on your protected directory.

Remove a user's permissions

To remove permissions for a user, use the setfacl command with the -R and -x options to recursively remove the access ACL and the default ACL entries for that user. For example, to fully remove access permissions granted to user user1234 for your protected directory and its contents:

1. Recursively remove the access ACL entries for the user (replace /path/to/your/protected with the path to your protected directory from above):

   setfacl -R -x u:user1234 /path/to/your/protected

2. Recursively remove the default ACL entries for the user (replace /path/to/your/protected with the path to your protected directory from above):

   setfacl -R -d -x u:user1234 /path/to/your/protected

Get help

If you need help or have a question, contact the UITS High Performance File Systems (HPFS) group using the Research Technologies contact form; from the "Choose an area to direct your question to" drop-down, select High performance storage.