Skip to main content

​
Overview

This tutorial shows how to use Sift data access governance (DAG) to protect resources such as Assets, Channels, and Runs. In this tutorial, you will:
  • Prevent a specific user from viewing an Asset and its Channels.
  • Keep the Asset accessible to other authorized users.
  • Create an explicit deny policy using DAG.
  • Block access to an Asset containing sample satellite telemetry.
  • Restrict a user’s existing permissions without changing their role.

​
DAG summary

In DAG, users and resources are labeled with attributes. Policies evaluate those attributes to determine whether access should be allowed. Here’s a brief summary of DAG for this tutorial. For a detailed explanation, see the Data Access Governance (DAG) overview.
DAG adds granular access control on top of Sift’s role-based access control (RBAC).
  • Restrict access to specific data without changing a user’s role.
  • Apply security and export controls within the permissions already granted by RBAC.
  • Deny visibility to sensitive data that would otherwise be accessible.
  • Define scalable access policies that automatically apply as users, teams, and data grow.
  • Uses attributes for users and resources to enforce policies.
  • Evaluate these attributes when a user accesses a resource.
You use these three components to allow or deny access to specific data in Sift.

​
Prerequisites

Before you begin, make sure you have the following:
  • A general understand of Sift, as covered in the Sift Learning Path.
  • Access to the DAG feature.
    • Access is available only to Admins in organizations where DAG is enabled. If DAG is not enabled for your organization, contact Sift to request access.
  • An Asset named fl_leo that contains sample Low Earth Orbit (LEO) satellite telemetry data.
    1. Import this CSV file into Sift to create an Asset.
    2. For the Asset name, Replace fl in fl_leo with your initials. This helps avoid naming conflicts if others are also completing the tutorial on the same Sift instance.
    3. For the Run name, leave the default value.
    4. Do not modify any other settings.

​
Step 1: Create a user attribute

In this step, you will:
  • Create a user attribute that identifies users who should be denied access to the LEO Asset.
  • Define the attribute as a label that DAG policies can evaluate. You will use the attribute later when creating a policy that enforces access restrictions.
  1. In Sift, click your profile icon, and then select Manage.
  2. In Access Control, click User Attributes.
  3. Click Create User Attribute.
  4. In the Type list, select Boolean.
    Sift supports multiple data types for user and resource attributes. For this user attribute example, we select Boolean because we only need a simple Authorized/Not authorized flag. To learn more, see Attribute data types.
  5. In the Name box, enter: fl_leo_denied.
    Replace fl in fl_leo_denied with your initials (first and last name).
  6. In the Description box, enter: Users that should be denied access to the LEO Asset.
  7. Click Save.

​
Step 2: Assign the user attribute

Next you will assign the new user attribute to the user who should be denied access to the LEO Asset. Assigning this attribute does not immediately deny access. It only labels the user so that a policy can later reference this attribute.
  1. In Access Control, click User Attributes.
  2. In the User attributes table, find *_leo_denied.
  3. Click Options, and then select Assign.
  4. In Assign User Attributes, in Users, select a user for denied access, and click Assign.
    • You can select any user, but do not select yourself. You can change this selection later.
    • Once the policy is active, this user’s RBAC permissions will be further limited for this specific Asset. While they might still have a global View role, this DAG policy will further restrict it to deny access.
  5. In Assign to 1 user, set Boolean option to True.
    • We selected True because the policy you create later will match users where *_leo_denied is true and deny them access. Setting this value to True ensures the selected user matches the policy condition.
  6. Click Next.
  7. Review your changes, and then click Update.
At this point, no access has changed. The user still has the same RBAC role and permissions as before. Access will only be changed after you create a policy that checks for this attribute in a later step. Next, you’ll create a resource attribute to protect the LEO Asset.

​
Step 3: Create a resource attribute

In this step, you will create a resource attribute that identifies the LEO Asset you want to protect. Resource attributes describe what a resource is and allow DAG policies to target specific Assets, Channels, or Runs.
Creating the resource attribute at this point does not change access because resource attributes only take effect when they are referenced by a policy.
  1. In Access Control, click Resource Attributes.
  2. Click Create Resource Attribute.
  3. In Type, select Enum.
  4. In Name, enter: fl_leo_asset.
    Replace fl in fl_leo_asset with your initials (first and last name).
  5. In Description, enter: Identifies the LEO Asset protected by DAG.
  6. In Value Options, enter: leo.
  7. Click Save.

​
Step 4: Assign the resource attribute to the Asset

Now that you have created the *_leo_asset resource attribute, you must apply it to the LEO Asset.
DAG enforces access inheritance between related resources. By assigning the attribute to the Asset, you protect the Asset and its related data without tagging each resource individually.
  • Channels: If a user is denied an action on an asset, the same action is automatically denied on all channels belonging to that asset. Denying viewDetails on the Asset removes both the Asset and all of its Channels from the user’s view.
  • Runs: Access inheritance for runs applies only to viewing telemetry data (viewData). To view data on a run, the user must have viewData access to at least one of the run’s associated assets. Other actions on runs (such as editing details) are evaluated on the run independently. For this tutorial, denying viewDetails on the Asset is sufficient — it hides the Asset and its Channels from the restricted user.
  1. In Access Control, click Resource Attributes.
  2. In Resource Attributes, find *_leo_asset.
  3. Click Options, then select Assign.
  4. In search field, enter the name of the LEO Asset you created (for example, *_leo).
  5. In the search results, select your LEO Asset.
  6. Click Assign.
  7. In Enum, select leo.
  8. Click Next.
  9. Review your changes, and then click Update.
Once you assign this label, nothing changes yet. Access will only be affected after you create the policy in the next step to connect the user and resource attributes.

​
Step 5: Create the access policy

In this step, you will create the DAG policy to enforce access control (preventing the selected user from seeing the LEO Asset). The policy connects the user attribute and the resource attribute you created earlier. The active policy will no longer be visible to that user in Sift.
  1. In Access Control, click Policies.
  2. Click Create Policy.
  3. In the Policy name box, enter: fl_deny_leo_asset_access.
    Replace fl in fl_deny_leo_asset_access with your initials (first and last name).
  4. Select Deny.
    • A Deny policy sits silently in the background and only triggers when a user matches your specific “denied” criteria. When a match occurs, this policy adds a restriction within their RBAC permissions to block access for that specific resource.
  5. Select All users (default).
    • All users ensures the policy acts as a global guardrail across the entire organization.
  6. Select the Asset checkbox.
    • This scopes the policy to target only Assets, ensuring efficient evaluation against the fl_leo_asset tag you created earlier.
  7. Select the ViewDetails checkbox.
    • Since your goal is to hide the sensitive LEO data, by denying the ViewDetails action, you completely remove the Asset from the user’s interface.
    • Because of inheritance, denying ViewDetails on the Asset automatically prevents the user from viewing any Channels or Runs inside it.
  8. Set conditions. Create the following conditions:
    • Once you create the policy, the user you assigned fl_leo_denied: true will no longer be able to see the Asset you tagged with fl_leo_asset: leo in Sift.
  9. Click Create.
  10. Review your policy, and then click Create policy.
You can open a policy and click View as Cedar policy to see a human-readable Cedar version.Cedar is an open source language for defining permissions as policies, and a specification for evaluating those policies. Companies use Cedar to define who is authorized to do what within an application.This policy is stored in Sift and editable and verifiable via the API using the Cedar Access Control domain specific language.

​
Conclusion

In this tutorial, you learned how to:
  • Use DAG to surgically deny access to a sensitive Asset.
  • Create a user attribute to flag restricted users
  • Create a resource attribute to identify the target data
  • Create a policy to enforce the block.
  • By using an explicit deny, you ensured that the restriction overrides any existing permissions, while the inheritance logic automatically protected all data Channels within the Asset.
You can now scale this security model simply by assigning the fl_leo_denied attribute to any other user you need to restrict, without ever needing to modify the policy itself.