Overview: Managing access to controlled data with Authorization Domains

Anton Kovalsky
  • Updated

Learn about Authorization Domains and when you need their additional layer of security for controlled-access data. For step-by-step instructions and troubleshooting, see How to set up and use an Authorization Domain.

IMPORTANT! Using authorization domains to secure PHI is  your responsibilityNIH Grants Policy Statement section 2.3.12 reminds recipients of their "vital responsibility to protect sensitive and confidential data as part of proper stewardship of federally funded research, and take all reasonable and appropriate actions to prevent the inadvertent disclosure, release or loss of sensitive personal information."

Securing data in a cloud-native environment

You may be surprised to learn that data in the cloud can be more secure than data stored locally. This is because in a cloud-native platform, security is built-in, and less dependent on individuals. Terra has several layers of effective protection for your data and tools, which is why the platform has achieved FedRamp moderate compliance.

Read on to understand how workspace permissions and Authorization Domains work together to provide strong built-in protection for your data in Terra. 

Workspace permissions - the first line of defense

Terra workspace permissions protect primary data stored in a Terra workspace. Assigning reader, writer, can-share, and owner roles protects sensitive data while allowing collaborators to work efficiently.

Workspace permissions protect access to

  • Data in the workspace Bucket
  • Data in tables
  • Analysis tools 

To simplify the process and minimize human error, workspace permissions can be set for a managed group (instead of individual users). See Managing access to shared data and tools with groups.

Limitations of workspace permissions

While using managed groups reduces the risk of forgetting to remove or update permissions when team members change, managing workspace permissions places the burden on individual owners to ensure security. This can be a problem, especially in more complex scenarios, such as when sharing data across multiple workspaces or with external collaborators. 

Eliminating human error with Authorization Domains

Using workspace permissions get tricky when authorized collaborators make clones and generate derived data in their own workspaces. This is where Authorization Domains (ADs) provide a higher level of security.

Authorization Domains are managed groups that strictly enforce permissions within a workspace and any copies (clones) of that workspace. Only those who are part of the assigned Authorization Domain can access data and tools in shared workspaces and any clones. This approach removes the need for manual tracking of permissions across cloned workspaces, offering stronger protection against accidental sharing.

Example: Security in Workspace cloning

Consider a scenario where your lab is working with sensitive primary data stored in a Terra workspace. 

If your colleagues have can share permission, there’s a risk they could unintentionally share the workspace and expose controlled data with unauthorized users.

If the original workspace has an Authorization Domain, however, only those within the AD group can access or clone the workspace. Because Authorization Domains follow the clone, unauthorized users won’t be able to view any data (primary or generated) unless they belong to the AD. Unless they are a member of the AD, they won't be able to view an AD-protected workspace, even if it's shared with them. This automated protection simplifies the process and eliminates the risk of human error.
AD-Use-Case_Single-lab-single-project_Step3.png

Assigning an Authorization Domain to a workspace

  • Ensures secure access to the workspace and all clones for all members of the AD.
  • Automatically extends permissions to all derived workspaces and data without the need for manual updates.
  • Significantly reduces the risk of accidental sharing or unauthorized access.

When to use an Authorization Domain

ADs are most useful when you need to guarantee access control of not only the primary data (stored in workspace storage or a data table) but to all generated data, including data generated by a colleague (or a colleague of a colleague...).

For example, working with federally-controlled data may require a workspace protected with an Authorization Domain.

Note that ADs can be useful even if your primary data is stored in an external bucket or platform which requires authorization. In this case, the Authorization Domain protects access to data generated from the primary data (stored externally) and stored in the workspace Bucket. 

Note that absent legally binding access restrictions, workspace permissions may be sufficient. 

Workspace permissions

Authorization Domains

  • Grant access to users in a managed group
  • Protect access to primary data stored in
    • data tables
    • workspace Bucket)
  • Can be adjusted/updated by workspace owners at any time.
  • Restrict access to only individuals in the group
  • Protect access to all data generated in Terra from the primary data.
  • Assigned to workspaces when they are created and follow all workspace copies. 
  • Cannot be removed

Do you need an authorization Domain?

Workspace permissions are sufficient for many use cases See the questions below to help decide if you should assign an Authorization Domain for additional protection.

1. Is primary protected data stored in the workspace?

Authorization Domains are inherited, so they are most effective when applied to workspaces that contain primary, controlled data (in the workspace Bucket or data tables).

2. Do you need to control what collaborators do with their own clones of the workspace?

Collaborators with "can share" permission on the workspace with may make their own copies of the original, which they can then share.

While it is easy to control the permissions of the primary workspace, it can be hard  to keep track of access once collaborators make their own shareable copies. The owner of the original workspace has no control over them sharing with others outside the original group. Authorization Domains can be useful in this case.

3. Is there a well-defined group of people who should have access?

It's easier to set up an AD for a group that already has well-defined membership.

One example: A consent group approved by an IRB or other agency to use controlled data stored in a workspace bucket. An Authorization Domain that includes only the consented users can protect primary data in the Workspace bucket as well as any generated data, no matter who generates or in what workspace it's generated.

Another example: To allow workspace sharing with a certain, well-defined, set of colleagues (as in a given institution). Note that you can change the individuals in an AD group, but you cannot share a workspace with anyone outside the AD.

4. Do you anticipate sharing with people who are not on the Authorization Domain?

To ensure protection of controlled data, authorization domains are a permanent fixture for workspaces that use them. There is no easy way add collaborators to workspaces with an AD, unless you also add the collaborators to the AD.

Some Authorization Domain examples

Below are examples of how you might use ADs to protect controlled data for different collaboration scenarios.

  • Step 1: The PI or PM creates one Lab-wide Authorization Domain, and adds researchers in the lab consented to use the data (i.e., those listed as dbGAP downloaders under the PI) to the AD group. 

    AD-Use-Case_Single-lab-single-project_Step1.png

    Step 2: The Authorization Domain group is included when creating any workspaces for that project. The workspace - and all copies of that workspace - are protected by the Authorization Domain

    AD-Use-Case_Single-lab-single-project_Step2.png

    Result: Only researchers consented to use the data can access, copy, or work in the workspaces (this overrides workspace permissions)

    AD-Use-Case_Single-lab-single-project_Step3.png

  • Step 1: PI or PM creates several Authorization Domain groups, one for each data consent group and adds researchers to all of the data consent groups that include them. 

    AD-Use-Case_Single-lab-many-projects_Step1.png

    Step 2: PI creates a primary workspace for each project, and includes the appropriate Authorization Domain. Note: A workspace could be protected by more than one AD, depending on the data (i.e., if a workspace combines data from two consent groups, it will have two Authorization Domains) 

    AD-Use-Case_Single-lab-many-projects_Step2.png

    Result: A researcher must be included in all the workspace ADs to access a protected workspace

    AD-Use-Case_Single-lab-many-projects_Step3.png

  • Step 1: PI at one institution creates a project-specific authorization Domain for one consent group. Collaborators in both institutions are added to the Authorization Domain for the data they are consented to use.  

    AD-Use-Case_Cross-Institute-Collaborations_Step1.png


    Step 2:
    Collaborating institution creates a second Authorization Domain

    AD-Use-Case_Cross-Institution-Collaboration_Step2.png


    Result:
    Collaborators can access only the workspaces with data they are consented to use, regardless of what institution created the workspace or what institution they are at.

    AD-Use-Case_Cross-Institution-Collaboration_Step3.png

Additional resources

To learn more about linking to external servers, see Linking authorization/accessing controlled data on external servers.

Was this article helpful?

1 out of 1 found this helpful

Comments

0 comments

Please sign in to leave a comment.