Permission management and isolation

Tenant isolation

Dataphin uses tenants to isolate resources. Data, nodes, members, and permissions are completely isolated between different tenants. You can share data and nodes only through cross-tenant publishing. Two common scenarios are:

• Two separate, physically isolated Dataphin deployments. For example, two different companies can each have their own Dataphin deployment. A single company can also deploy separate Dataphin instances for its development and production environments.

• Two logically isolated Dataphin tenants within a single deployment. For example, a large company with multiple business lines can create a separate tenant for each business.

Project isolation

• Within a tenant, you can use projects to manage data developers, data nodes, and data tables.

• By default, members and data are isolated between different Dataphin projects. This isolation prevents cross-project data access and maximizes data security. To access data from another project for business needs, you can request permissions for the tables created by that project or request to join the project.

• This differs from tenant isolation. Tenants cannot access each other. However, different projects can access each other if the required permissions are requested and granted.

In addition to basic user and data permission isolation, two other secure configurations are available:

• Cross-project safe mode: This mode prohibits cross-project Data Definition Language (DDL) operations. You can create and modify tables only within the current project. This clarifies management permissions.

• Read and write permission request switch: If a project contains highly sensitive data, you can disable the feature that allows members outside the project to request read and write permissions. This setting provides better protection for sensitive data.

Project member role assignment

Dataphin uses project roles to manage the operations that members can perform and the data they can view. When you add a project member, you must assign a role. Different roles have different feature and database permissions. Proper role configuration helps prevent issues such as sensitive data leakage or unauthorized operations. You can change a member's role or remove a member. When a role is changed, the member's permissions are updated immediately. Before you remove a member, you must manually change the owner of all objects owned by that account. This avoids disrupting future permission approvals or editing operations.

Dataphin provides the following built-in project roles:

• Project administrator

  Manages project members. Has permissions to add, delete, modify, and publish project files, including normalized modeling objects. Has permission to perform operations on project nodes. Has developer permissions for all physical tables in the project. Cross-project permissions are subject to the tenant's security policy.

• Project visitor

  Has permission to view project files, including normalized modeling objects and task nodes in the project. Does not have database permissions for objects in the project and must request them separately. Cross-project data access permissions are subject to the tenant's security policy.

• Data visitor

  Has permission to view project files, including normalized modeling objects and task nodes in the project. Has query permissions for all physical tables in the project. Cross-project permissions are subject to the tenant's security policy.

• Analyst (Can only be configured for single-environment projects or development projects)

  Has permission to view project files, including normalized modeling objects and task nodes. Has permissions to add, delete, and modify ad hoc query files in the project. Has query permissions for all physical tables in the project and permission to create tables in the project. Cross-project permissions are subject to the tenant's security policy.

• Developer (Can only be configured for single-environment projects or development projects)

  Has permissions to add, delete, and modify project files, including normalized modeling objects. Has permission to submit and publish files to update production schedules and perform monitoring and operations and maintenance (O&M) in Basic mode. Has permission to perform operations on project nodes. Has developer permissions for all physical tables in the project. Cross-project permissions are subject to the tenant's security policy.

• O&M (Can only be configured for single-environment projects or production projects)

  Has permission to publish project files from the development environment to the production environment in Dev-Prod mode. Has permission to perform operations on task nodes in the project. Has developer permissions for all physical tables in the project. Cross-project permissions are subject to the tenant's security policy.

Dataphin also supports custom project roles for more flexible, fine-grained permission management. You can customize the following permissions for a role:

• Planning: Includes permissions to manage project members and configure project information and business entities.

• Integration: Permissions to view, edit, and execute data integration features.

• Development: Permissions to view, edit, and execute Data Studio features.

• Project data assets: Includes permissions granted by the role to access data assets in the current project, such as physical and logical tables. These permissions can include querying, modifying, and deleting tables. Data asset permissions are a key reason for creating custom project roles. Grant the minimum required permissions.

• Publishing and O&M: Includes permissions to view, publish, and remove objects, and to perform O&M operations or modify resource configurations. Note that the O&M features for a developer role are effective only in the O&M module of the development environment. To operate on published production nodes, you must have O&M-related permissions in the production project.

Production and development isolation

Dataphin provides several solutions for isolating production and development environments. The solutions are listed below, from the lowest to the highest level of isolation:

• No production and development isolation: This runs in a basic, non-isolated pattern. This basic pattern is suitable for users who do not have strong requirements for project isolation and are concerned about resource consumption costs.

• Logical isolation within the same tenant: Business segments and projects use an isolated production and development pattern. This pattern uses publishing controls to manage the development and production environments, which better ensures the security of production changes and data. We recommend that you enable production and development isolation for business segments and projects to achieve complete data isolation. To better protect production data, you can also set a production data safe mode. When this mode is enabled, you cannot perform DDL operations on the production environment from the development environment.

• Logical isolation between different tenants in the same deployment instance: This method uses different tenants for development, staging, and production environments. It also isolates the underlying compute engines. This logically isolates code and configuration rules and completely isolates data. Publishing in this way requires cross-tenant publishing of nodes.

• Complete physical isolation: This involves deploying two completely separate Dataphin instances. You can deploy the different instances in different network environments for physical isolation. This method also requires cross-tenant publishing of nodes.

Permission requests and grants

Besides using projects and roles, you can also obtain permissions through individual requests and grants.

Dataphin currently supports individual requests and grants for permissions on data tables, data sources, functions, variables, keys, and DataService Studio.

• Permission requests

  When you need to use a table or data source, you can submit a permission request in the permission center. The request must be approved by the owner of the resource or the administrator of the module. You can also customize approval policies for different resources. For more information, see Permission request and approval policies.

• Permission grants

  • As a resource owner or module administrator, you can directly grant permissions for the resources you manage to other members.

  • All permission requests, approvals, and grants are recorded in the permission audit module. This helps with future compliance reviews. For more information, see Permission audit.

When a personal account or user group requests permissions, or when you grant permissions to them, you can set an expiration period. To ensure that permissions are used appropriately, grant them for the shortest time necessary. If your job responsibilities change or you leave the company, you must return any permissions you have requested or been granted.

Permission request and approval policies

Dataphin has rich, built-in approval policies for different resources. You can also customize approval policies based on your company's needs. If you have your own Office Automation (OA) system, Dataphin can integrate with it for approvals.

• Built-in permission request and approval policies

  Dataphin has different built-in approval policies for different resources. For example, permissions for Dataphin physical tables must be approved by a project administrator. Permissions for logical tables must be approved by a business segment administrator.

• Custom permission request and approval policies

  Dataphin lets you customize approval policies based on resource type, the project the resource belongs to, and whether sensitive data is involved. For example:

  • If no sensitive data is involved, you can allow use without approval.

  • If sensitive data is involved, you can require approval from a project administrator and a security administrator.

  • You cannot request permissions for top-secret data.

• Support for integration with customer OA systems

  If you want to complete permission approvals in your own OA system, Dataphin can integrate with it. The approval workflow is forwarded to your OA system. After approval, the result is sent back to Dataphin to complete the actual grant.

Data download control

Dataphin lets you download data results. You can download the results from code tasks and ad hoc analysis to your local computer for further use. For projects that involve confidential or top-secret data, administrators need to control data download behavior.

Dataphin provides the following two features to control data downloads:

• Disable data result downloads: For top-secret data, you must control and prevent data downloads. You can disable the data result download feature for the entire project to prevent sensitive data leakage.

• Download approvals: For confidential data, you must approve the data, user, and scenario before a download can occur. Dataphin lets you configure download approvals for a project. You can require approval from a project administrator or a security administrator. This prevents sensitive data from being downloaded directly.