Dataphin:Permission control and isolation

Tenant isolation

Dataphin supports a robust tenant concept, ensuring complete isolation of data, tasks, members, and permissions between tenants. Cross-tenant circulation of these elements is strictly controlled through publishing mechanisms. Common scenarios include:

• Two separate, physically isolated Dataphin instances, such as those belonging to distinct enterprises or separate instances for an enterprise's test and production environments.

• Two logically isolated Dataphin tenants within a single deployment, enabling a conglomerate with multiple business units to maintain a dedicated tenant for each unit.

Project isolation

• Within a single tenant, projects serve as a means to manage data developers, data tasks, and data tables.

• By default, members and data across different Dataphin projects are isolated, preventing cross-project usage and ensuring optimal data security. Access to data from other projects requires explicit permission requests or project membership applications.

• Project isolation differs from tenant isolation in that, while tenants are completely segregated, projects within the same tenant can access each other through permission requests or authorizations.

In addition to the fundamental isolation of personnel and data permissions, Dataphin offers two supplementary security configurations:

• Cross-project safe mode: Restricts cross-project DDL operations, allowing table creation and modification solely within the current project, thereby clarifying management permissions.

• Read/write permission request switch: For projects containing highly sensitive data, this feature can be disabled to prevent external project members from requesting read or write access, further safeguarding sensitive information.

Project member role assignment

Dataphin enables precise control over the operations and data scope accessible to different project members through role assignments. When adding members to a project, each must be assigned a specific role, with distinct functional and data permissions. Proper role configuration is crucial for preventing unauthorized access and data breaches. Roles can be modified or members removed as needed, with immediate updates to permission scopes. Prior to member removal, a one-click transfer of managed objects is required to ensure uninterrupted permission management.

Dataphin provides several built-in project roles, including:

• Project administrator

  Granted comprehensive permissions to manage project members, handle project files, and operate project nodes. They also have development rights for all project physical tables, subject to tenant security policies.

• Project visitor

  Permitted to view project files and task nodes, with no inherent data permissions within the project. Separate applications are required for data access, governed by tenant security policies.

• Data visitor

  Allowed to view project files and task nodes, with query rights for all project physical tables, in line with tenant security policies.

• Analyst (configurable only for single-environment or development projects)

  Granted permissions to view project files, manage ad hoc query files, and view task nodes. They also have query rights and table creation rights within the project, subject to tenant security policies.

• Developer (configurable only for single-environment or development projects)

  Authorized to manage project files, update production schedules, and operate project nodes. They possess development rights for all project physical tables, with cross-project permissions regulated by tenant security policies.

• Operations and maintenance (configurable only for single-environment or production projects)

  Permitted to publish files from development to production environments and operate within-project task nodes. They have development rights for all project physical tables, with cross-project permissions subject to tenant security policies.

For more nuanced and flexible project role management, Dataphin supports role customization and permission assignment. Customizable aspects include:

• Planning: Determines whether project members can be managed and whether project information and business entities can be configured.

• Integration: Permissions for viewing, editing, and executing data integration functions.

• Development: Permissions for viewing, editing, and executing data development functions.

• Project data assets: Role-based permissions for data assets within the project, such as querying, modifying, or deleting physical and logical tables. It's recommended to tailor these permissions to the minimum necessary scope.

• Publish and operations: Permissions related to viewing, publishing, or removing objects, as well as modifying operations or resource configurations. Note that the development project role's operations function is only active in the development environment's operations module. Operations on production tasks require corresponding permissions in the production project.

Production and development isolation

Dataphin offers a spectrum of security isolation solutions for production and development environments, ranging from basic to advanced levels:

• No production and development isolation: A fundamental mode suitable for users with minimal isolation requirements and a focus on resource cost efficiency.

• Logical isolation within the same tenant: This mode allows business units and projects to manage development and production environments separately through publishing controls, enhancing the security of production changes and data. It is advisable to enable this mode at a minimum to ensure complete data control. Additionally, a production data safe mode is available to prevent DDL operations in the development environment, further protecting production data.

• Logical isolation across different tenant deployments: Utilizes separate tenants for development, testing, and production, with isolation at the compute engine level for code, configuration rules, and data. Cross-tenant publishing is required for task deployment.

• Complete physical isolation: Involves deploying two independent Dataphin instances, potentially in different network environments, for maximum physical separation. Cross-tenant publishing is also necessary in this scenario.

Permission requests and authorizations

Beyond project-based permissions and roles, Dataphin facilitates access to specific permissions through individual requests and authorizations.

Dataphin currently supports individual requests and authorizations for permissions related to tables, data sources, functions, variables, keys, and DataService Studio.

• Permission requests

  Users can initiate permission requests for specific tables or data sources in the Permission Center, which must then be approved by the resource owner or module administrator. Approval policies can be customized for different resources. For more information, see permission application approval policy.

• Permission authorizations

  • Resource owners or module administrators can directly grant managed resources to members in need.

  • Permission requests, approvals, and grant records are traceable within the permission audit module, aiding compliance reviews. For more information, see permission audit.

When individuals or user groups request permissions or are granted them proactively, the validity period can be set. It is advisable to choose the shortest necessary duration to ensure responsible use. Upon role changes or departure, users should return any permissions they have acquired.

Permission approval policies

Dataphin offers a variety of built-in permission approval policies for different resources and allows for customization based on enterprise needs. Integration with existing OA systems for approval processes is also supported.

• Built-in permission approval policies

  Dataphin includes various built-in approval policies tailored to specific resources. For instance, permissions for physical tables in Dataphin require project administrator approval, while logical table permissions necessitate business unit administrator approval.

• Custom permission approval policies

  Dataphin supports the customization of approval policies based on resource type, project association, and the involvement of sensitive data. For example:

  • Non-sensitive data may be used without approval.

  • Sensitive data requires approval from both the project and security administrators.

  • Top-secret data cannot be requested.

• Integration with customer OA systems

  For approvals within a customer's own OA system, Dataphin can integrate and forward the approval workflow, with the outcome returned to Dataphin for final authorization.

Data download control

Dataphin allows for the downloading of data results from code tasks and ad hoc analyses for business use. However, for sensitive data, administrators may need to regulate download activities.

Dataphin provides two mechanisms to control data downloads:

• Disable data result download: To prevent the leakage of top-secret data, the ability to download data results can be disabled for an entire project.

• Download approval: For confidential data, downloading requires prior approval from designated project or security administrators. This ensures that sensitive data is not downloaded without proper authorization.