Article on data access authorization and responsibility

[bdu-birhanu]

Pull Request

Overview

The aim of this PR is to introduce data access authorization and responsibilities of researchers/users of personal and shared Cheaha storage spaces and security Exceptions related to access to data from current and former personnel of UAB.

Proposed Changes

• Added two tables outlining the responsibilities of researchers/users for personal and shared Cheaha storage..

Related Issues

Fixes #635
Fixes #894

[wwarriner]

Great start! I want us to add LTS responsibilities as well. I believe if we do this right, the Cheaha and LTS responsibilities should be mostly the same. We may need some rows of the table to apply specifically to one or the other.

I think with a bit of rewording, we can get the two existing tables to work for both GPFS and LTS.

[wwarriner]

I think this section of the storage main page will be relevant: https://docs.rc.uab.edu/data_management/storage/#data-responsibilities-and-procedures. It should probably become part of the page being developed here.

Then add two questions to the main page like "How can I effectively manage my data?" and "What are my responsibilities for data management?"

[wwarriner]

We also need to add a section reminding folks of other responsibilities around data that come from Enterprise IT. These apply to all UAB-owned computer systems, including Research Computing systems.

• Overall IT policy page: https://www.uab.edu/it/home/policies
• Acceptable Use Policy (AUP): https://secure4.compliancebridge.com/uab/portal/getdoc.php?file=300
• Data Protection and Security Policy: https://secure4.compliancebridge.com/uab/portal/getdoc.php?file=302
• Data Access Policy: https://secure4.compliancebridge.com/uab/portal/getdoc.php?file=301
• Data Classification: https://www.uab.edu/it/home/policies/data-classification/classification-overview

[wwarriner]

In line with the Enterprise IT policy information, we need to add that information to the responsibility table(s).

Some additional rows to consider

• Data management, PI
• Creating and maintaining metadata, PI
• Maintaining permissions and access controls, PI (this may be redundant)
• Compliance with regulatory controls (HIPAA, NIST 800-171, etc.)
  • Administrative (authorization and access), PI
  • Technical (encryption, firewall, etc.), RC
  • Physical (locks, cameras, sign-ins, etc.), RC
• Obtaining security exceptions when required, PI
• Operating expenses, RC
• Hardware capital expenses (up to default quota), RC
• Hardware capital expenses (beyond default quota), PI

[wwarriner]

One last thing for the current review: make sure the names of storage offerings matches what is in the data management pages. Individual vs shared, calling storage "allocations" instead of "accounts" or "spaces".

[bdu-birhanu]

I think this section of the storage main page will be relevant: https://docs.rc.uab.edu/data_management/storage/#data-responsibilities-and-procedures. It should probably become part of the page being developed here.

Then add two questions to the main page like "How can I effectively manage my data?" and "What are my responsibilities for data management?"

Done.

[wwarriner]

Looks good overall, some changes that need to be made to avoid miscommunications, and a change to one of the tables.

Please also back out the .pre-commit-config.yaml change. You can keep the change on your local machine until we merge #896, but let's keep it out of this PR.

[wwarriner]

Overall looks good. A couple minor things and we can set it to be merged.

[wwarriner]

This is coming along well!

I realized we could do with a couple of changes to the CSVs, and there are a few language and wording changes. The backup section could be a cross-link to where it is in the storage.md article.

Once these changes are in, I plan to present this to Ralph for review. He will have insights onto things we are missing, or language changes we may need.

Great work so far, thank you!

[wwarriner]

Looks good! In the future, keep file content changes in separate commits from renaming/moving files. I have the same habit of committing content and moving files together. When we do that, it makes it very hard for diff tools to pick up the changes to the file. Instead it looks like we deleted one file and added another file.

To be specific, first change the file and commit the work. Then, change the name of the file (or move it) and commit again.

Don't worry about undoing anything this time, but please separate them for next time. I'll work on breaking my own habit as well!

[wwarriner]

This is ready to merge from my perspective. I'd like to have Ralph look it over prior to merging, so I will leave as review.

[wwarriner]

A couple of changes from Ralph's notes and suggestions, then we can merge.