Managing data privacy and access with Authorization Domains
Because research is frequently collaborative, you need to be able to keep sensitive genomic data secure, but still easy to share. Terra was designed to help you balance these competing requirements. Read on to see how.
Contents
Securing controlled-access data in a cloud-native environment
- Traditional approach to data security
- Improving data security with authorization domains
A step by step guide to setting up and using authorization domains
Securing controlled-access data in a cloud-native environment
A researcher needs authorization to work with sensitive (i.e. controlled) data. On Terra, you would have a project workspace to analyze data and store any generated files. Let's assume that the derived data must still be controlled.
Traditional approach to data security
Let’s say the data are private to your lab and stored in a workspace bucket. You know you are a member of your lab (indicated by the blue color in the diagram above), so you can access your lab’s data (also blue) in the workspace.
You clone the original workspace, run an analysis, and generate derived data. This is possible because your role gives you permission to copy the that workspace and access the data in the original workspace bucket.
If a new coworker asks you to share your workspace with them, you would (traditionally) be responsible for checking that this new coworker is officially a part of your lab rather than an imposter (unlikely, but still)! You are the owner of the cloned workspace, with no restrictions on how or with whom you share it. You’d have to keep track for yourself which of your fellow scientists have up-to-date authorization.
Assuring security with authorization domains
Enter Authorization Domains, which are like a badge that allows access to workspaces only for people with the same badge. When you clone a workspace that has an Authorization Domain, the badge stays with the new copy, and anyone who wants to access the copy has to have the badge. You no longer need to worry about accidentally sharing sensitive data because if you try to share the cloned workspace with a user who doesn’t have the right badge, that researcher won’t be able to enter.
Let’s revisit our example from before, but with the addition of Authorization Domains. The PI sets up the original workspace where the sensitive data are store, and includes an Authorization Domain to control access to the data. You are in your lab’s Authorization Domain, and you’re working with a workspace that also has the lab’s Authorization Domain. You do your analysis, generate some derived data, and create a clone.
Since all ADs are inherited, the copied workspace also has the lab Authorization Domain. When you try to share the workspace with your new coworker, the authorization domain will check to see if your coworker is in the Authorization Domain, or if they are an imposter (or more likely, need to ask to be added to the AD).
Either way, the Authorization Domain keeps track of access so you don't have to. And because Authorization Domain lists can be updated and modified, it's easy to adjust as those in the lab come and go.
A step-by-step guide to setting up and using Authorization Domains
(steps 1 and 2 shown above)
Step 1: Set up a group (i.e. give users their badges)
Before you can assign an Authorization Domain to a workspace, you will need to set up an authorization domain group. There are two ways to set up and manage groups, depending on whether you use a third-party or user-defined group
Third-party groups (TCGA, TARGET, GTEx)
User-defined groups
Step 2: Set the workspace Authorization Domain
When creating a workspace, you can select one or more groups for the Authorization Domain. (If you don’t see your group in the list, you may need to create it. See Step 1 above).
An Authorization Domain can only be set when creating the workspace, and once set, it cannot be removed from the workspace. It will be copied over to any cloned version of the workspace to keep any derived data protected.
When an Authorization Domain includes multiple groups
Consider a workspace whose Authorization Domain contains both the TCGA and Target groups. If a user is invited to the workspace, the system checks both the TCGA and the Target access lists for their accounts before allowing access.
When importing data from a workspace with Authorization Domain protection
For example, if the destination workspace has TCGA-dbGap-Authorized and Tiffs-Test-Group groups in the Authorization Domain, you can import data from workspaces whose Authorization Domain is set to TCGA-dbGap-Authorized only, Tiffs-Test-Group only, both groups, or no groups. If the source workspace had additional groups, you would not be able to import from it. In this example, Terra informs you there are six workspaces that are unavailable because of this.
Step 3: Share the workspace
To complete the process, you can now share the workspace, either with the group you used in the Authorization Domain, or with an individual.
Step-by-step
If you share with individuals or a group who is not in the Authorization Domain, they will see the workspace greyed out in their workspace list. When they click it, Terra facilitates a request process that sends an email to all owners of the groups in the Authorization domain. Once the user has the proper badge(s), they can enter the workspace to see the protected data.
You can also create new workspaces within existing authorization domains so that users already in that authorization domain will already have the proper permission to enter that workspace once it is shared with them:
Comments
0 comments
Please sign in to leave a comment.