Secure research data containing HIPAA-regulated PHI on the Data Capacitor II, Slate, or Slate-Project file systems at IU

On this page:


Overview

The Research Technologies division of UITS provides several systems and services that meet certain requirements established in the HIPAA Security Rule thereby enabling their use for research involving data that contain protected health information (PHI). However, using a UITS Research Technologies resource does not fulfill your legal responsibilities for protecting the privacy and security of data containing PHI. You may use these resources for research involving data containing PHI only if you institute additional administrative, physical, and technical safeguards that complement those UITS already has in place. 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 the Data Capacitor II (DC2), Slate, or Slate-Project high-performance file systems.

Note:

Encryption

IU data management standards require that files containing PHI be encrypted at rest. To further enhance the security of research data containing PHI stored on the DC2, Slate, or Slate-Project file systems:

  • 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 IT Pro for help.
Note:
When you transfer a file to DC2, Slate, or Slate-Project from a device with full-disk encryption, the file will be decrypted prior to transfer. If you want the file to arrive encrypted, you must encrypt the file itself while it's still stored on your device.

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 DC2, Slate, or Slate-Project file system (replace username with your IU username or my_project with the name of your project):

  • DC2 scratch space:
    mkdir /N/dc2/scratch/username/protected
    
  • DC2 project space:
    mkdir /N/dc2/projects/my_project/protected
    
  • Slate:
    mkdir /N/slate/username/protected
    
  • Slate-Project:
    mkdir /N/project/my_project/protected
    

Make sure only you have access

The permissions for 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 on DC2, Slate, or Slate-Project 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 on DC2, Slate, or Slate-Project 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
Important:
Never use chmod to grant group permissions to your protected directory.

About Access Control Lists (ACLs)

The DC2, Slate, and Slate-Project file systems support POSIX Access Control Lists (ACLs). The use of ACLs provides granular control for sharing data with other IU research supercomputer users, allowing you to grant individual users or groups access to specific files and directories.

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:

user::rwx The owner has read (r), write (write), and execute (x) permissions for the named directory.
group::r-x The owning group has read and execute permissions for the named directory.
other::r-x Other users outside the owning group have read and execute permissions for the named directory.

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 on DC2, Slate, or Slate-Project. 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):

    • DC2 scratch space:
      setfacl -m u:user1234:rx /N/dc2/scratch/username
      
    • DC2 project space:
      setfacl -m u:user1234:rx /N/dc2/projects/my_project
      
    • Slate:
      setfacl -m u:user1234:rx /N/slate/username
      
    • Slate-Project:
      setfacl -m u:user1234:rx /N/project/my_project
      

    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 on DC2, Slate, or Slate-Project.

    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 on DC2, Slate, or Slate-Project 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 on DC2, Slate, or Slate-Project 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 on DC2, Slate, or Slate-Project 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 on DC2, Slate, or Slate-Project.

    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 on DC2, Slate, or Slate-Project 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 on DC2, Slate, or Slate-Project 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 on DC2, Slate, or Slate-Project from above):
    setfacl -R -d -x u:user1234 /path/to/your/protected
    
Note:
Do not use the setfacl command's -b option to remove all ACL entries; doing so may cause problems on some file systems. For more about the setfacl command and its options, see the setfacl manual page (man setfacl).

Get help

If you have questions about securing HIPAA-regulated research data at IU, email securemyresearch@iu.edu. SecureMyResearch provides self-service resources and one-on-one consulting to help IU researchers, faculty, and staff meet cybersecurity and compliance requirements for processing, storing, and sharing regulated and unregulated research data; for more, see About SecureMyResearch. To learn more about properly ensuring the safe handling of PHI on UITS systems, see the UITS IT Training video Securing HIPAA Workflows on UITS Systems. To learn about division of responsibilities for securing PHI, see Shared responsibility model for securing PHI on UITS systems.

If you need help or have a question about using your DC2, Slate, or Slate-Project space, contact the UITS High Performance File Systems (HPFS) team.

This is document avhc in the Knowledge Base.
Last modified on 2020-07-01 10:44:45.

Contact us

For help or to comment, email the UITS Support Center.