Access model overview
Data Control Tower implements a model that you might find in other types of software called Attribute Based Access Control (ABAC). This model is incredibly flexible but requires detailed configuration to perfect your use cases. In our model, there are four entity types which are defined below. Understand each entity as they are the foundational blocks of DCT’s ABAC model.
Entity | Description | Managed By |
|---|---|---|
Accounts | A single or shared user who can authenticate with DCT (UI or API). | Create manually or via Identity Provider (IdP), such as SSO or LDAP. Accounts are independent of Delphix Engines. |
Access Groups | A collection of accounts that share one or more characteristics, such as a Team or Permission set. Equivalent to an Active Directory group. | Manually created. Populated manually or via the ‘login_groups’ tag. |
Roles and Permissions | The collection of read, write, and delete permissions forms a reusable, named role. | Some roles are provided out of the box, but Admins can build their own from the available permissions. Individual permissions are immutable. |
Objects | Units, such as VDBs, Bookmarks, and Environments, that are managed across the Delphix Platform. | Automatically identified by DCT from the connected engines. Assigned to Roles via various models. The CD and CC Engines supply these objects. |
Each entity is linked to another through manual or automated assignment. A manual (or direct) assignment is a good approach for early implementations. However, it can be challenging to maintain as teams grow. As an alternative, Tagging is suggested as it performs automatic assignments based on your custom configuration. The below diagram shows how each entity is linked together. The directions below start with Accounts creation to Access Groups with Role assignments and finish with Object mappings.
Understanding your team structure is imperative to identify the best access model. Usually, organizations have existing groupings defined in their Identify Provider (IdP). These groups are typically organized in one of two ways (a) a team dedicated towards a central goal (such as a product development team) or (b) a group of individuals with similar permissions (such as Security Administrators). Understanding the purpose of each group should be a guide in how the Roles and Permissions are designed. For example, the Alpha product development team might have full permission to manage existing VDBs and create new bookmarks for their team’s “Alpha” objects. On the other hand, Security Admins might have sweeping read and disable access across the entire platform to ensure compliancy. Iterating through each Access Group and designing custom, but re-useable roles, based on the Principle of Least Privilege, will produce a streamlined rollout.